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1  INTRODUCTION. 

This  document  contains  a  concise  description  of  the  system  under  the  cognizance  of  the 
Advanced  Distributed  Simulation  Technology  (ADST)  contract  at  the  end  of  the  twelfth  quarter 
(March  10,  1991  through  March  10,  1994).  This  system  includes  elements  of  the  Battlefield 
Distributed  Simulation  -  Development  (BDS-D)  Program,  such  as  the  two  BDS-D  Test  Bed 
sites  at  Fort  Knox  and  Fort  Rucker.  The  BDS-D  system  is,  in  large  part,  driven  by  BDS-D 
Program  exit  criteria  ^  The  first  major  steps  toward  satisfying  these  exit  criteria  were  taken  in 
the  BDS-D  Architecture  Delivery  Orders  (D.O.s)  which  have  resulted  in  the  Architecture 
Documents^. 

This  document  is  also  complementary  to  the  BDS-D  Guidebook^.  The  BDS-D  Guidebook  is 
designed  to  acquaint  the  customer  with  the  Battlefield  Distributed  Simulation  -  Developmental 
(BDS-D)  Program,  the  ADST  Program,  and  the  purposes  and  relationships  of  each  of  these 
programs.  The  guidebook  answers  some  of  the  more  frequently  asked  questions  concerning 
the  program  and  the  benefits  and  oppomn  ities  it  can  provide.  This  document  provides  the 
most  current  description  of  the  components  that  make  up  the  BDS-D  system. 

This  description  includes  references  to  other  documents  which  have  been  identified  as 
comprising  the  most  complete  description  of  the  current  system  with  coverage  of  all  system 
aspects  and  minimum  redundancy.  Where  no  such  existing  document  is  available  (for 
example,  for  a  program  in  progress  which  has  not  yet  resulted  in  deliverable  documentation), 
the  System  Definition  Document  will  provide  this  information  where  appropriate. 

This  document  is  divided  into  sections  discussing  the  system's  physical  and  operational 
configuration  and  its  software  configuration.  Additional  information  is  provided  on  key 
systems  engineering  activities,  such  as  configuration  management,  standards,  databases,  and 
information  services. 

A  short  discussion  is  attached  in  Appendix  A  on  the  research  areas  given  in  the  ADST 
Statement  of  Work  (SOW).  This  discussion  describes  the  ways  in  which  various  efforts, 
mostly  through  D.O.s,  have  contributed  to  these  areas.  Appendix  B  provides  a  list  of  ADST 
Points  of  Contact. 

This  document  addresses  the  configuration  of  the  core  system,  as  well  as  changes  made 
through  D.O.s  and  Engineering  Change  Orders  (ECOs)  during  the  year.  The  current  status  of 
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ADST  Delivery  Orders'*  is  provided  in  Table  1-1.  Appendix  C  provides  a  list  of  deliverables 
and  products  by  delivery  order.  Finally,  a  glossary  of  terms  and  list  of  references  is  provided 
in  Appendix  D. 


Table  1-1.  ADST  Delivery  Orders 


ACTIVE  DELIVERY 
ORDERS 

POTENTIAL  DELIVERY 
ORDERS 

COMPLETED  DELIVERY 
ORDERS 

BDS-D  Architecture  Definition  & 
DIS  Standards  Development 

XMDEWS 

Hollis  Experiment 

Horizontal  Integration 

ARWA  Phase  II 

Land  Systems  Funire  Battlefield 

MDT2 

AUSA  May  Demonstration  1994 

Leavenworth  Node 

DOS  Training  Delivery  Order 

05/06  TOC 

Seamless  Simulation  Experiment 

Jayhawk  Thunder 

FARV 

Smart  Minefield  Simulator 

BDS-D  System  Definition  ‘Support 

Fox  NBCRS 

CVCC  Battalion  Formative 
Evaluation 

ModSAF 

DISCSS 

Battlefield  SyiKhronization 
Demonstration 

1  MULTIRAD 

Anti-Armor  ATD 

X-Rod  (Experimental  AT  Missile) 

1  A^ATD  Phase  II 

CVCC  93  Tests 

1  Non-Line-of-Sight 

CSRDF  -  BDS-D  Interface 

1  Advanced  Rotary  Wing  Aircraft 

1  Phase  I 

AirNet  AeroModel  and  Weapons 
Model  Conversion 

1  Vehicle  Integrated  Defense  Systems 
(VIDS)  Phase  III 

Rotary  Wing  Aircraft 

Infoscope 

MULTlRADAVarbieaker  I 

National  Guard 

VIDS  Phases  I  and  II  1 

Stingray 

Jayhawk  Thunder  Phase  I  1 

Dynamic  Terrain 

SASC  Demonstration  | 

GuardFIST 

M 1 A2  Superthreats  1 

Testbed  Expansion 

Skalnotty 

AUSA  Fetmiary  Demonstration 

1993 

DOTD 

2  PHYSICAL  CONFIGURATION. 

The  physical  configuration  of  the  system  includes  the  computers,  networking,  and  other 
equipment  and  subsystems  required  to  conduct  a  distributed  interactive  simulation  session. 

The  primary  emphasis  of  the  experiments  and  exercises  conducted  on  this  system  is  on  soldier- 
in-the-loop  simulation.  Additionally,  information  about  the  geographical  sites  which  house  the 
equipment  is  provided. 


2 


ADST/WDLrrR--9-iM)30 1 7-V3.0 
1994 


ADST  System  Definition  Document 


10  March 


2.1  Simulators  and  Simulation  Support  Assets. 

Table  2.1-1  lists  the  various  simulators  and  some  of  their  capabilities. 
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Table  2.1-1.  Simulator  Characteristics 
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2.1.1  Combat  Vehicle  Command  and  Control  (CVCC)  Simulator. 

2. 1.1.1  CVCC  Tank  Description. 

The  CVCC  simulator  is  a  hybrid  M 1  tank  simulator  with  several  future  tank  design  features. 
This  simulator  incorporates  a  position  navigation  system,  a  commander’s  independent  thermal 
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viewer ,  and  a  modified,  more  complex  version  of  the  inter-vehicular  information  system.  In 
additioD,  it  has  a  thermal  channel  for  the  gunner. 


2. 1.1.2  CVCC  Tank  Operations. 


The  user  manual  for  the  tank  utilized  for  the  CVCC  test  is  titled  SIMNET  Combat  Vehicle 
Command  and  Control  (CVC2)  System  (BBN,  December  19905).  The  Inter-Vehicular 
Information  System  (IVIS)  has  its  own  user  manual,  SIMNET  CVCC  IVIS  Utilities  User 
Manual  (BBN  Report  No.  7631,  July  1991^). 


2.1.2  Data  Logger. 

2. 1.2.1  Data  Logger  Description. 


The  data  logger  is  an  MC5600  MASSCOMP  computer  with  a  high-performance  Ethernet 
interface  to  the  simulation  netwoiking  (SIMNET)  network.  The  data  logger  can  capture  the 
network  traffic  and  place  the  data  packets  in  a  disk  or  tape  file.  Given  the  two  data  logging 
mediums  of  disk  and  tape,  logging  a  disk  file  is  performed  by  specifying  a  medium  of  disk; 
and  logging  onto  magnetic  tape  is  performed  by  specifying  a  medium  of  tape.  The  data  logger 
performs  the  following  functions; 

a.  Packet  Recording:  Receives  packets  from  the  SIMNET  networic,  time-stamps  them, 
and  writes  them  to  a  disk  or  tape. 

b.  Packet  Playback:  Packets  fix>m  a  recorded  exercise  can  be  transmitted  in  real  time  or 
faster  than  real  time.  The  data  logger  can  also  suspend  play  back  (freeze  time)  and  skip 
backward  or  forward  to  a  designated  point  in  time.  The  logger  can  be  ctmtrolled 
directly  from  the  keyboard  or  remotely  from  the  PVD.  Playback  is  visible  to  any  device 
on  the  netwoik  (PVD,  stealth  vehicle,  vehicle  simulator,  etc.). 

c.  Copying  or  Converting:  Hies  are  copied  to  another  file,  which  can  be  on  the  same  or  a 
different  medium;  and  files  from  the  older  version  of  the  data  logger  can  be  converted  to 
a  format  compatible  with  the  current  version  of  the  data  logger. 


2. 1.2.2  Data  Logger  Operations. 

The  current  user  manual  for  the  data  logger  is  SIMNET  Data  Logger  (BBN  Report  No.  7617, 
June  1991^). 
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2.1.3  Fixed  Wing  Aircraft  (FWA). 

The  FWA  is  configured  as  a  single  pilot  device  and  replicates  the  flight  dynamics  and 
munitions  of  a  USAF  A- 10  Wart  Hog  aircraft  It  is  armed  with  the  Maverick  missile. 
Sidewinder  missile,  and  the  30mm  GAU-8  gun.  The  FWA  also  requires  a  dedicated  GT-111 
Computer  Image  Generator  (CIG),  but  its  visual  effects  are  slightly  different  than  those 
described  for  the  RWA.  Like  the  RWA,  the  FWA  uses  two  rows  of  TV  monitors,  three 
monitors  on  the  top  row  and  five  monitors  on  the  bottom  row,  for  OTW  views.  Unlike  the 
RWA,  the  FWA  does  not  have  FLIR  or  day  TV  capability,  but  uses  the  CIG's  high  resolutif 
channel  to  provide  a  heads-up  display  (HUD)  and  a  7  kilometer  OTW  view  on  the  bottom 
row's  center  monitor.  In  the  OPFOR  mode,  the  FWA  replicates  the  characteristics  of  a  Soviet 
Su-25  Frogfoot  aircraft  armed  with  appropriate  munitions. 

2.1.4  Generic  Air  Defense  Devices  (GADDs). 

The  generic  air  defense  device  is  configured  for  a  crew  of  three  (driver,  gunner/electro-optical 
operator,  and  squad  leader/radar  operator).  The  device  requires  a  dedicated  GT-1 1 1  CIG, 
which  emulates  most  behaviors  of  an  air  defense  system.  The  CIG  also  provides  a  3500  meter 
OTW  view  via  four  vision  blocks  for  the  driver,  a  FLIR  and  day  TV  threat  detection  range  of  7 
km,  and  a  laser  range  of  10  km.  Additionally,  the  device  features  radar,  with  a  selectable  range 
of  either  15  km  or  25  km,  which  is  driven  by  a  Concurrent  6600  computer  connected  to  a  CIG 
and  the  network.  The  device  is  armed  with  eight  air  defense  missiles  which  can  only  be 
launched  while  the  vehicle  is  stationaiy. 

The  generic  air  defense  devices  are  the  ADATS  or  FAADS  vehicles.  The  actual  replication  of 
these  devices  was  for  the  Forward  Heavy  Line  of  Site  Heavy  Air  Defense  Systems. 

2.1.5  Line-of-Sight  Anti-Tank  (LOSAT). 

The  LOSAT  is  an  experimental  anti-tank  system  based  on  a  Bradley  IFV  chassis  with  a  hyper¬ 
velocity  anti-tank  missile  system.  This  simulator  was  built  on  site  with  on-hand  simulator 
components.  The  LOSAT  unique  software  was  installed  to  replicate  system  functionality. 

2.1.6  Management  Command  and  Control  (MCC). 

The  MCC  system  is  responsible  for  simulating  a  variety  of  combat  and  combat  service  support 
functions.  These  include  ammunition  trucks,  maintenance  vehicles,  fuel  trucks,  artillery 
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pieces,  mortars,  command  posts,  ground  mine  emplacements  devices,  and  bombs.  The  host 
for  the  MCC  is  an  MC56(X)  MASSCOMP  computer,  which  incorporates  a  68020 
microprocessor,  two  megabytes  of  memory,  a  142-megabyte  hard  disk,  a  floppy  disk  drive,  a 
cartridge  tape  drive,  an  Ethernet  interface,  and  an  eight-channel  RS-232  interface.  Users 
communicate  to  the  MCC  through  six  Apple®  Macintosh  computers  via  an  AppleTalk  netwoik 
and  an  RS-232  line.  The  AppleTalk  network  features  an  intermediary  Macintosh  called  the 
bridge,  which  translates  between  the  AppleTalk  protocols  understood  by  the  Macintosh 
consoles  and  the  RS-232  signals  supported  by  the  MCC  host.  Brief  descriptions  of  the  six 
Macintosh  computer  flinctic'S  follow; 

a.  Simulation  Control  Console.  The  SCC  are  used  to  start  an  operation,  establish  the 
scenario  within  which  the  operation  takes  place,  initially  place  select  vehicles  on  the 
terrain,  and  cany  out  functions  (such  replacing  destroyed  vehicles)  normally  performed 
by  echelons  above  the  particular  battalion  to  which  the  user  is  assigned. 

b.  Close  Air  Support.  The  CAS  console  directs  aircraft,  armed  with  500  pound  dumb 
bombs,  against  battlefleld  targets  in  either  a  preplanned  or  on-call  modality. 

c.  Fire  support.  The  fire  support  console  issues  orders  to  one  of  three  155  howitzer 
batteries  and  to  a  mortar  platoon  in  eitl^r  a  preplanned  or  an  immediate  call-for-flre 
modality. 

d.  Combat  Engineer.  The  combat  engineer  console  allows  the  user  to  emplace,  breech,  or 
move  minefields  on  the  terrain. 

e.  Admin/logistics.  The  administration  and  logistics  console  moves  trucks  carrying 
ammunition  and  fuel. 

f .  Maintenance.  The  maintenance  console  dispatches  maintenance  vehicles  and  recovery 
teams. 

2. 1.6.1  MCC  Workstations  Operations. 

The  user  manual  for  the  Combat  Service  Support,  Fire  Support,  Close  Air  Support, 
Admin/Log,  Maintenance  and  Exercise  Initiation  workstations  is  SIMNET  Master 
Documentation  fPerceptronics.  15  September  1986^). 

2. 1.6. 2  Engineer  Workstation  Operations. 

The  operations  documentation  for  the  Combat  Engineer  MCC  console  is  Technical  Report  No. 
PTR-4070-1 1-8200-91/29. 
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Z1.7  Ml  Tank. 

2. 1.7.1  Ml  Description. 

The  M 1  tank  device  is  a  real-time  simulation  of  the  Ml  Abrams  main  battle  tank  configured  for 
a  crew  of  four  (driver,  commander,  guimer,  and  loader).  The  device  is  clocked  in  real-time  at 
15  Hz  in  lockstep  synchronization  with  a  dedicated  GT-101  CIG.  The  GT-101  CIG  generates 
eight  low  resolution  channels  (seven  are  for  vision  blocks  and  one  is  for  the  gunner's  primary 
sight  (GPS))  and  emulates  most  behaviors  of  a  real-world  M 1 .  The  crew  operates  in  a 
buttoned-up/closed  hatch  mode  and  views  the  virtual  world  through  1  power  vision  block 
which  provides  vision  out  to  3500  meters.  The  simulator's  visual  system  permits  the  crew  to 
search  for  and  track  targets  and  terrain  features,  and  to  maintain  tactical  formation  while 
moving.  The  GPS  is  shared  by  the  commander  and  features  selectable  3x  and  I  Ox 
magnification.  The  device  is  armed  with  the  105mm  main  gun  only  and  is  capable  of  firing 
high  explosive  antitank  (HEAT)  and  sabot  munitions. 

2. 1.7. 2  Ml  Operations. 

The  current  Ml  operations  manual  is  SIMNET  Manual  No.  PTUM  001-1250-89-10  (Rev. 

2)10. 

2.1.8  M1A2  Tank. 

2. 1.8.1  M1A2  Description. 

The  Ml  A2  incorporates  a  Position  Navigation  (POSNAV)  system,  a  Commander's 
Independent  Thermal  Viewer  (CITV),  and  an  Inter- Vehicular  Information  System  (IVIS).  The 
Ml  A2  is  unique  in  that  the  simulation  by  General  Dynamics  Land  Systems  (GDLS)  is  created 
on  the  VME  chassis  and  interfaces  with  the  GT-1 1 1  CIG  with  a  modified  set  of  interface  cards. 
The  CIG  creates  the  graphics  and  interfaces  with  the  VME  chassis  through  the  Ethernet  creating 
the  simulation. 


Fort  Knox  has  made  extensive  use  of  the  MIA2  simulators  for  training,  doctrine,  and  combat 
development  activities. 
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2. 1.8. 2  M1A2  Operations. 

The  current  operators  manual  was  produced  by  GDLS  under  contract  DAAE07-91-R001, 
Individual  -  Conduct  of  Fire  Trainer  (I-COFT),* 

2.1.9  M2/M3. 

2. 1.9.1  M2/M3  Description. 

The  M2/M3  device  replicates  the  shooting,  moving,  and  communicating  modes  of  the  M2/M3 
BFV  and  is  configured  for  a  crew  of  three  (driver,  commander,  and  gunner).  Like  the  Ml 
above,  the  BFV  requires  a  dedicated  GT-101  CIG.  As  with  the  Ml,  the  CIG  generates  eight 
low  resolution  channels  (seven  are  for  vision  blocks  and  one  is  for  the  gunner's  integrated 
sight  unit  (ISU)).  The  crew  operates  in  a  closed  hatch  mode  and  views  the  virtual  world 
through  1  power  vision  block  which  provides  vision  out  to  3500  meters.  The  ISU  is  shared  by 
the  commander  and  features  selectable  4x  and  12x  magnification.  The  device  is  armed  with  a 
25mm  chain  gun  capable  of  firing  high  explosive  and  armor  piercing  ammunition  and  the  Tube- 
launched,  Optically  Wire-guided  (TOW)  missile. 

2. 1.9. 2  M2/M3  Operations. 

The  current  operations  manual  covering  the  M2/M3  is  SIMNET  Manual  No.  PTUM  (X)2-1250- 

89-10  (Rev.  1)12 

2.1.10  Non-Line-of-Sight  (NLOS)  System. 

The  NLOS  system  is  a  fiber-optic  guided  forwmd  area  air  defense  and  anti-armor  missile 
system  which  uses  both  TV  and  imaging  infrared  (HR)  missiles.  The  NLOS  simulated  at  the 
A  VTB  is  the  light  version  which  is  mounted  on  the  high  mobility  multipurpose  wheeled  vehicle 
(HMMWV),  carries  six  missiles,  and  is  operated  by  a  two-member  crew  (driver  and  guimer). 
The  system  also  simulates  a  single  channel  ground  and  airborne  radio  system  (SINCGARS) 
and  an  enhanced  position  location  and  reporting  system  (EPLRS).  It  requires  a  dedicated 
ESIG  2000  or  GT-1 1 1  CIG,  which  emulates  behaviors  of  a  HMMWV  and  a  FOG-M  plus 
provides  four  channels  of  low  resolution  OTW  video  with  a  field  of  view  of  approximately  160 
degrees  horizontal  by  30  degrees  vertical.  Maximum  visual  range  is  3500  meters.  A  higher 
resolution  video  channel  serves  the  gunner's  sensor. 
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2.1.11  Plan  View  Display. 

2.1.11.1  Plan  View  Display  Description. 

The  PVD  is  powered  by  an  MC5600  MASSCOMP  computer  and  provides  high  resolution  and 
near  real-time  displays  of  data  packets  received  from  all  vehicles  on  the  network.  ITie  PVD 
allows  the  user  to  view  the  entire  database  or  zoom  in  to  a  defined  location  and  view  a  single 
vehicle.  The  PVD  also  provides  the  user  with  numerous  map  tools,  terrain  definition  options, 
intervisibility  checks,  and  overlay  functions.  It  also  connects  to  the  data  logger  for  remote 
control  of  exercise  playback. 

2.1.11.2  Plan  View  Display  Operations. 

The  current  user  manual  for  the  PVD  is  SIMNET  Plan  View  Display  (BBN  Report  No.  7618, 
June  199113). 

2.1.12  Rotary  Wing  Aircraft  (RWA). 

The  RWA  simulator  is  reconfigurable  as  either  a  scout  or  an  attack  aircraft.  It  is  configured 
with  three  seats,  two  of  which  are  manned  at  any  given  time,  by  the  pilot  and  either  the 
copilot/observer  (CPO)  or  the  copilot/gunner  (CPG).  The  simulator  provides  auditory,  tactile, 
and  visual  stimuli  to  replicate  the  effects  of  shooting,  flying,  and  communicating.  Visual 
effects  are  generated  through  eight  TV  monitors  by  a  dedicated  GT- 1 1 1  CIG.  The  CIG 
outputs  eight,  low  resolution  chaimels,  each  chaimel  providing  a  25  x  15.6  degree  view  of  the 
virtual  world  out  to  3.5  kilometers;  and  one  high  resolution  chaimel  for  the  sensor  system  with 
a  visual  range  of  7  kilometers.  The  total  fleld  of  view  available  is  125  degrees  horizontal  and 

30.2  degrees  vertical.  The  out-the-window  (OTW)  views  are  vertically  slewable  and  update  in 
real  time  (at  a  15  Hz  frame  rate)  as  the  aircraft  flies.  The  device  OTW  is  vertically  slewable  in 
that  the  view  plane  can  be  moved  vertically  +  or  -  35®.  Consequently,  the  actual  vertical  field 
of  view  available  is  100.2  degrees.  The  sensor  views  replicate  day  TV  and  forward  looking 
infrared  (FLIR)  and  have  various  fields  of  view  that  are  selectable  by  the  CPO  or  CPG.  These 
devices  can  replicate  either  U.S.  or  Soviet  RWA.  Each  RWA  is  fully  instrumented  for  data 
collection  with  an  installed  TV  camera  mounted  inside  the  device,  and  a  gun  camera  replication 
tied  to  the  sensor  system.  Data  collection  is  effected  by  two  time-stamped  synchronized 
video/audio  recording  devices;  one  for  the  sensors  and  one  for  the  cockpit  The  simulator  can 
be  armed  with  3()mm  carmon,  Hellfire  missiles.  Air  to  Air  Stinger  (ATAS),  TOW,  50  caliber 
gun,  and  Hydra  70  rockets.  In  the  opposing  forces  (OPFOR)  mode,  it  is  armed  with  Soviet 
counterpart  munitions. 
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2.1.13  Semi-Automated  Forces  (SAFOR). 

2.1.13.1  SAFOR  Description. 

SAFOR  is  a  system  of  workstation-controlled  computer  generated  forces  that  interact  with 
maimed  simulators  on  the  battlefield.  SAFOR  units  are  commanded  by  the  workstation 
operator,  who  can  execute  pre-plaimed  scenarios  or  create  responses  to  the  situation  as  it 
happens.  Each  workstation  is  capable  of  creating  up  to  a  battalion  size  force. 

SAFOR  is  a  computer  representation  of  physical  performance  capabilities  of  a  system  plus  the 
human  behavior  representation.  SAFOR  provides  doctrine  and  tactics  for  the  force  being 
represented.  The  man-in-the-loop  is  there  to  correct  or  modify  the  behavior  as  required.  The 
purpose  of  SAFOR  is  to  provide  a  richer  battlefield  environment  without  being  manpower¬ 
intensive. 

The  SAFOR  workstation  allows  users  to  interact  with  the  semi-automatic  forces  system  and 
allows  for  man-in-the-loop  supervisory  control  of  air  and  ground  SAFOR.  Two 
configurations  of  SAFOR  are  currently  used  within  BDS-D.  The  original  is  built  around 
Symbolics  hardware,  which  operates  in  a  Genera  software  environment  and  consists  of  a 
black-and-white  (B&W)  monitor,  a  color  monitor,  a  keyboard,  and  a  mouse.  To  generate 
requisite  simulation  and  interface  with  the  local  simulation  network,  it  is  connected  to  a  MIPS 
2000  simulation  computer.  The  latest  version  has  lehosted  and  enhanced  the  Symbolics  front- 
end  onto  a  MIPS  3000.  The  user  can  effect  such  functions  as  unit  creation,  menu-style  input, 
message  display,  and  execution  of  system  functions  on  the  B&W  monitor.  The  color  monitor 
is  used  to  display  terrain,  effects,  and  units.  It  provides  mouse-sensitive  graphics  facilities  to 
adjust  map  scale  and  resolution,  to  issue  orders  to  units  (including  combat  instruction  sets, 
boundaries,  objectives,  and  routes),  and  to  establish  additional  control  measures  (such  as  phase 
lines,  firing  positions,  etc.). 

2.1.13.2  SAFOR  Operations. 

The  semi-automated  forces  are  operated  from  the  Symbolics  workstation,  which  consists  of  a 
keyboard,  monitor,  and  a  plan  view  display.  The  current  manual  on  how  to  operate  SAFOR  is 
Semi-Automated  Forces  (SAF)  Commander  Training.  SIMNET  (Perceptronics,  1 1  March 
1991 14)  SAFOR  Version  3.10.6,  released  on  15  July  1991  by  BBN,  is  the  SAF  used  at  the 
MWTB. 
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2.1.14  Shadow  Box. 

Another  viewing  platform,  the  Shadow  Box,  provides  the  test  officer  with  the  capability  to 
view  exactly  what  the  crew  members  see.  The  Shadow  Box  consists  of  four  video  monitors 
slaved  to  selected  video  channels  in  an  individual  simulator.  Since  the  signal  slaved  to  the 
Shadow  Box  is  the  exact  signal  sent  to  one  of  the  nine  views  in  the  simulator,  what  is  seen  at 
the  Shadow  Box  is  the  exact  view  seen  from  the  view  port  from  which  it  has  been  slaved.  This 
gives  the  test  officer  the  capability  to  see,  first  hand,  what  the  crew  members  see. 

2.1.15  Stealth. 

The  stealth  device  is  a  simulated  observation  vehicle  unrelated  to  any  real-world  vehicle.  It  acts 
like  an  invisible  eye  on  the  virtual  world.  The  Stealth  allows  the  test  officer  to  literally  fly 
around  and  view  the  simulation  without  interfering  with  the  action  in  the  simulation.  The 
stealth  is  a  passive  device,  having  special  flight  modes  which  make  it  the  fastest  and  most 
maneuverable  vehicle  on  the  database.  Stealth  features  allow  the  observer  to  view  the 
battlefield  from  a  variety  of  perspectives.  These  include  a  tethered  view  which  allows  the  user 
to  follow,  unnoticed;  an  individual  vehicle,  mimic  view,  which  places  the  user  in  the  vehicle 
and  provides  the  same  view  as  the  vehicle  commander,  an  orbit  view  which  allows  the  operator 
to  remain  attached  to  a  vehicle  on  the  database  and  revolve  360  degrees  still  maintaining  the 
vehicle  as  a  center  point  of  view;  and  the  free  fly  mode,  which  replicates  independent  3-way 
movement  on  the  battlefield. 

The  Stealth  system  is  a  viewing  platform  that  consists  of  a  plan  view  display  (PVD),  an  IBM 
compatible  PC  with  a  touch  screen,  a  “Space  Ball”  data  input  device,  and  three  50  inch  screen 
viewers,  providing  the  operator  a  panoramic  view  of  the  battlefield.  The  stealth  is  driven  by  an 
MC5600  MASSCOMP  computer.  Its  graphics  are  generated  from  a  BBN  120TX/T  image 
generator  or,  preferably,  a  GT  101  image  generator  (which  eliminates  the  requirement  for  the 
MASSCOMP). 

2.2  ADST  Sites. 

There  are  three  main  ADST  sites,  including  the  Mounted  Warfare  Test  Bed  (MWTB),  Fort 
Knox,  KY,  the  Aviation  Test  Bed  (AVTB),  Fort  Rucker,  AL,  and  the  Program  Management 
Office  (PMO)  and  Software  Development  Facility  (SDF)  in  Orlando,  FL.  In  addition,  the 
ADST  Program  provides  field  engineering  support  for  the  Institute  for  Defense  Analysis 
(IDA),  located  in  Reston,  VA. 
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2.2.1  Fort  Knox  Mounted  Warfare  Test  Bed  (MWTB). 

The  Fort  Knox  Mounted  Warfare  Test  Bed  (MWTB)  is  a  distributed  simulation  consisting  of 
several  local  area  networks  (LANs).  Each  LAN  is  an  Ethernet  linking  several  simulators, 
workstations  or  smaller  networks.  The  simulation  can  consist  of  either  manned  simulators  that 
replicate  specific  combat  vehicles  such  as  the  Ml  A2  main  battle  tank,  or  computer  generated 
forces  that  model  a  particular  vehicle  or  combat  organization.  The  MWTB  is  separated  into 
four  basic  operational  areas:  the  simulator  bay,  the  data  collection  and  analysis  area,  the 
maintenance  room,  and  the  administrative  offices.  Refer  to  Figure  2.2. 1-1  for  the  layout  of  the 
MWTB  and  to  Figure  2.2. 1-2  for  the  MWTB  functional  diagram. 


A  OST/VVDl  JTo  r,  ^ 


ADST/WDL/rR--94-030 1 7-V3.0 
1994 


Waiting 
Roon>  , 


I  ADST  System  Definition  Document 

Mounted  Warfare  Test  Bed 


Site 

Site 

Site 

Site 

{  Site 

"N^Staff 

Stall^ 

■N^Staff 

Staff  ^ 

10  Mard 


3on(erenc 

Room 


Classroom 


Site 

site 

Staff 

Staff 

Computer 

Room 


Workroom 


ICustoi 


Space 


Customer 

Office 

Space 


Field 

Engineer 

Workshop 


Supply  Room 


Exercise 
Control 
Room  / 


M1A2  M1A2  M2 

M1A2  M1A2  M2 


LOSAT 

LJ 


Stealth 


:vcd  Ncvcc 


CVCC 

Simulation  Bay  Area 


CVCC  CVCC  c\ 


Figure  2.2. 1-1.  Mounted  Warfare  Test  Bed  Facility  Layout 
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Figure  2.2. 1-2.  Mounted  Warfare  Test  Bed  Functional  Diagram  (2  of  2) 
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The  simulator  bay  houses  the  simulators  and  associated  equipment  used  in  the  research  efforts. 
It  operates  on  a  208  volt  three  phase  overhead  power  bus,  with  24  drop  line  locations  for 
providing  power  to  the  simulators.  The  Ethernet  and  radio  tray  run  parallel  to  the  power  bus. 
The  three  lines  are  color  coded  providing  easy  recognition  of  the  individual  systems.  A 
computerized  environmental  control  unit  monitors  and  adjusts  the  temperature  and  humidity 
throughout  the  building,  maintaining  an  environment  conducive  to  the  optimum  function  of  this 
highly  computerized  operation.  Several  uninterrupted  power  source  outlets  are  located 
throughout  the  bay.  These  outlets  are  primarily  used  for  powering  automated  data  collection 
equipment  which  is  sometimes  operated  in  the  bay  instead  of  the  computer  room.  Two  rooms, 
one  at  each  end  of  the  bay,  can  be  configured  for  experimental  control  operations.  Test  officers 
will  often  establish  their  test  control  operation  in  one  of  these  rooms  in  order  to  segregate  the 
test  participants  from  the  simulation  operators  and  data  collection  personnel.  This  provides  a 
more  secure  evaluation  and  minimizes  the  potential  for  data  contamination  during  the  test. 

The  Maintenance  area  contains  the  tools,  spare  parts,  and  work  space  necessary  to  ensure 
efficient  operation  and  conduct  repairs  on  ail  electronic  components  in  the  facility.  The 
maintenance  operation  routinely  conducts  repairs  down  to  board  level,  and  occasionally  down 
to  component  level.  The  maintenance  area  consists  of  two  rooms:  a  technician's  work  room 
and  a  storage  room.  The  storage  room  contains  spare  parts,  consumables,  reconfigurable 
simulator  components,  and  a  small  simulator  fabrication  shop. 

Administrative  offices  house  personnel  who  provide  resource  scheduling,  supply  requisition, 
personnel  management,  security,  and  safety  services  as  an  integral  part  of  the  operation  of  the 
MWTB.  Administrative  functions  are  accomplished  by  coordinating  operations  and  schedules 
among  the  site  staff,  various  clients,  and  the  U.  S.  Army  Technical  Oversight  Representative 
(TOR).  A  communications  net  enhances  communication  not  only  within  the  confines  of  the 
site,  but  throughout  the  ADST  network  of  facilities.  The  Electronic  Information  Exchange 
Network  (EIEN)  has  provided  an  enhanced  method  of  communicating  throughout  the  ADST 
world,  creating  a  setting  for  speedy  resolution  of  problems. 

The  facility  currently  houses  15  simulator  shells:  8  CVCC  simulators,  4  Ml  A2  simulators,  2 
M2/3  simulators,  and  1  LOS  AT  simulator  (see  Table  2.2. 1-1).  At  present,  there  are  not 
enough  computer  image  generators  in  the  facility  to  power  all  simulators.  The  CIGs  used  in 
this  facility  are  GT-1 !  Is,  which  have  eight  low  resolution  channels  and  one  high  resolution 
channel,  creating  a  total  of  nine  possible  channels  for  image  generation.  The  recently  acquired 
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M2/3s  are  configured  to  use  the  120T/Butterfly  CIG,  which  have  eight  low  resolution  channels 
and  no  high  resolution  channels. 


Table  2.2.1  -1 .  Major  Equipment  at  the  MWTB 


desc'RIWIAW 

4 

MIA2  Simulators 

8 

CVee  Simulators 

2 

1 

LOSAT  Simulator 

1 

STEALTH 

2 

Shadow  Box 

4 

4 

PVD 

3 

MCC 

1 

Long  Haul  Net 

2 

1 

1 

a.  Terrain  Databases.  The  simulation  takes  place  on  a  computer  generated  virtual 
battlefield  which  is  developed  from  a  terrain  database.  Maps  and  charts  are  supplied. 
Databases  being  used  include  the  NTC  database,  the  SAKI  database,  the  Bosnia 
database,  the  Fort  Knox  database,  and  the  Fort  Hunter-Liggett  database.  A  complete 
list  of  the  available  databases  can  be  found  under  Terrain  and  Sensor  Databases. 

b.  Long  Haul  Gateway.  A  Long  Haul  Gateway  is  installed  in  the  MWTB.  It  consists  of  a 
BBN  T20  connected  to  a  T-1  telephone  line  capable  of  channeling  one  and  a  half 
megabits  of  data  per  second.  The  BBN  T20  is  capable  of  including  eight  voice 
chaimels  along  with  the  simulation  PDU  traffic.  Through  this  system,  the  analog  voice 
is  digitized  at  the  sending  end  and  converted  back  to  analog  at  the  receiving  end.  Diis 
allows  separate  sites  to  simultaneously  interact  with  each  other  on  the  same  terrain. 

c.  Gateway  Security.  Fort  Knox  is  in  the  process  of  installing  a  secure  gateway  to 
support  encrypted  long  haul  exercises. 

d .  Data  Logging.  As  a  test  or  simulation  is  being  run,  the  data  is  transmitted  over  an 
Ethernet  in  a  series  of  packets  or  protocol  data  units  (PDUs).  These  PDUs  are 
normally  recorded  on  any  one  of  three  data  logger  MASSCOMP  5600  data  recorders 
located  in  the  computer  room.  The  data  is  normally  recorded  on  9-track  tape  and  then 
analyzed  on  a  VAX  cluster  comprised  of  workstations  and  a  Micro  VAX  file  server. 
The  analysis  is  not  slaved  to  the  simulation  and  can  be  accomplished  while  another 


ADST/WDIjTR-94-030  i  7- V3.0 
1994 _ 


ADST  System  Definition  Document 


10  March 


simulation  is  running.  Analysis  results  can  be  provided  to  the  user  in  the  form  of  hard 
copy  data  and  graphs,  9-track  file  tapes,  cassette  tape,  or  diskettes, 
e.  Data  Analysis.  The  Loral  team  on-site  staff  has  expertise  and  years  of  experience  in 
designing,  conducting,  evaluating,  and  reporting  experiments  in  Distributed  Interactive 
Simulation.  This  staff  includes  programmers  and  field  engineers  who  have  the 
technical  knowledge  required  to  assemble  simulators  and  test  networks  designed  to 
answer  a  customer's  questions  .  It  also  includes  research  scientists,  training 
developers,  systems  analysts,  and  data  technicians  who  can  plan,  conduct,  and  analyze 
the  results  of  these  experiments.  Finally,  it  includes  operations  specialists  and  subject 
matter  experts  with  military  backgrounds  who  can  ensure  that  the  experiments  are 
conducted  in  a  manner  which  is  doctrinally  sound. 

2.2.2  Fort  Rucker  Aviation  Test  Bed  (AVTB). 

The  Aviation  Test  Bed  (AVTB)  is  the  aviation  component  of  Battlefield  Distributed  Simulation- 
Developmental  Technology  and  provides  Department  of  Defense  agencies  with  an  aviation- 
oriented,  research  development  test  and  evaluation  (RDT&E)  facility  consisting  of  aviation, 
armor,  infantry,  air  defense  artillery,  and  non-line  of  sight  missile  systems  simulation  devices. 
The  AVTB  is  sponsored  by  STRICOM  and  the  United  States  Army  Aviation  Center  and  is  a 
government-owned,  contractor-operated  facility. 

In  a  training  development  role,  the  AVTB  serves  as  a  joint  and  combined  arms,  collective  task 
trainer  and  provides  real-time  simulations  which  replicate  battle  at  each  tactical  echelon,  team 
through  brigade-level,  inclusive  of  combat,  combat  support,  and  combat  service  support 
functions.  In  so  doing,  the  AVTB  allows  users  a  means  to  experiment  with  training  strategies 
and  collective  task  accomplishment  in  a  professional,  cost-effective,  and  safe  environment 

In  the  RDT&E  capacity,  the  AVTB  provides  users  with  a  cost  effective,  pre-prototype 
development,  systems  modeling  facility.  Ultimately,  users  can  simulate  before  they  build, 
buy,  or  fight  a  particular  combat  system.  The  site  provides  an  environment  in  which  users  can 
explore  the  capabilities  that  should  be  incorporated  into  a  new  system,  investigate  the  numbers 
and  allocation  of  the  system  that  achieve  optimum  performance  on  the  battlefield,  and  determine 
the  best  means  to  employ  the  system  once  it  is  built.  It  provides  a  research  laboratory  for 
doctrine,  force  structure,  materiel  acquisition,  and  training  and  leadership  development. 
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The  complex  offers  users  an  environment  with  visitor  office  space;  administrative  support;  a 
conference  room;  a  classroom  with  TV/VCR,  overfiead  and  3Smm  slide  projection  capabilities, 
and  stealth  functions;  a  student  break  area;  and  two  tactical  operations  centers  complete  with 
requisite  maps,  charts,  and  radio  communications.  The  site  also  offers  a  real-time  data 
reduction  and  analysis  center  and  is  an  approved  classified  (secret-level)  processing  facility. 
Additionally,  the  site  contains  a  Video/ Audio  Data  Production  Center  (VADPC).  The  VADPC 
exponentially  increases  customer  service  capability  by  providing  state-of-the-art  video 
manipulation  equipment.  Specific  capabilities  include  dubbing,  editing,  splicing,  and 
monitoring  all  standard  and  super  VHS  mediums.  Cited  capabilities  are  based  on  time  stamp 
information  synchronization  for  instant,  firame-by-fiame  recall.  The  VADPC  provides  a  new 
dimension  in  customized  customer  services  and  additional  depth  to  simulation  playback  and 
after-action  review  activities. 

In  terms  of  manned  and  simulated  device  interface,  all  vehicle  simulators  and  their  supporting 
elements  communicate  via  local  area  and  long  haul  networks.  Simulators  within  the  complex 
are  linked  via  a  10  megabit  per  second  Ethernet.  The  Ethernet  is  connected  to  a  single  long 
haul  network  by  a  gateway.  Table  2.2.2- 1  describes  the  major  components  of  the  AVTB. 
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Table  2.2.2- 1 .  Major  Equipment  at  the  A  VTB 


DESCRIPTION  1 

1 

2 

Local  area  networks 

2 

AppleTalk™  netwoiks 

8 

Rotary  wing  aircraft  (RWA  )simuIation  devices 

2 

Fixed  wing  air  (FWA)  simulators 

2 

Ml  Abrams  tank  simulators 

2 

1 

2 

Plan  view  displays  (PVD)  powered  by  Massachusetts  I 

Computer  Corp,  (MASSCOMP™)  5600  computers  1 

4 

Semi-automatic  forces  (SAFOR)  workstations 

4 

Generic  air  defense  simulators 

2 

Non-line  of  sight  (NLOS)  /fiber-optic  guided  missile 
(FOG-M)  simulators 

2 

Management  command  and  control  systems  (MCC) 

2 

Simulation  networking  control  consoles  (SCC) 

1 

1 

Fire  support  Macintosh  workstation 

1 

Combat  engineer  Macintosh  workstation 

1 

Administration  and  lomstics  Macintosh  workstation 

1 

Maintenance  Macintosh  woijcstation 

i 

Data  loggers  powered  by  MC56(X)  MASSCbMP 
computers 

8  " 

Bolt,  Baranek,  and  Newman  (BBN)  GT-1 1 1  computer 
image  generators  (CIGs) 

4 

BBN  GT-lOl  CIGs 

1 

1 A 1 M  AVifc>.#sr«!i.ilrf»T7TTii  •  t  hi  inl 

1 

iag..^/i,tT.iiai?Tniwrri[TTg^ 

2 

T1  Terrestrial  Wideband  Gateways 

1 

Encrypted  Longhaul  Sptem 

1 

Video  Teleconierence  System 

1 

PC  SAS  Data  Output  Terminal  | 

For  introductory  purposes,  all  vehicle  simulators  and  their  supporting  elements  communicate 
via  local  area  and  long  haul  networks.  Simulators  within  the  complex  are  linked  via  a  10 
Megabit  per  second  Ethernet.  The  Ethernet  is  connected  to  a  single  long  haul  network  by  a 
gateway. 


In  addition  to  the  aforementioned  components,  the  complex  offers  users  with  linuted  office 
space;  limited  administrative  support;  a  conference  room;  a  classroom  with  TVA^CR,  overhead 
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and  35nim  slide  projection  capabilities;  a  student  break  area;  and  two  tactical  operations  centers 
complete  with  requisite  maps,  charts,  and  radio  communications.  A  layout  of  the  AVTB  site  is 
shown  in  Figure  2.2.2- 1.  A  hmctional  diagram  is  shown  in  Figure  2.22-2. 

Aviation  Test  Bed 


MINUTE  MAN  STREET 


NIGHTHAWK  STREET 


Figure  2.2.2- 1 .  Fort  Rucker  Aviation  Test  Bed  Facility  Layout 
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Figure  22.2-2.  Aviation  Test  Bed  Functional  Diagram  (1  of  2) 
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Figure  21.1-1.  Aviation  Test  Bed  Functional  Diagram  (2  of  2) 
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a .  Tactical  Conununications.  The  A  VTB  uses  a  combinadon  of  hard-wired  citizen  band 
radios  and  army  telephones  (TA-3 12)  to  effect  tactical  communications  for  both 
research  and  development  and  training  development  requirements.  Requisite  command 
and  control,  combat,  combat  support,  combat  service  support,  and  administrative 
communication  networics  are  facilitatol  in  the  manner.  A  communications  diagram  is 
provided  in  Figure  2.2.2-3. 

b.  Data  Analysis.  Data  analysis  is  performed  using  a  DEC  Micro  VAX  3600  Computer 
with  VMS  operating  system  and  RS/1  and  DataProbe  extraction  and  analysis  software. 
Data  recorded  on  the  data  logger  is  transferred  by  1/2"  magnetic  tape  to  the  Micro  VAX 
where  it  is  processed,  producing  tabulated  data,  which  can  then  be  manipulated  in  a 
variety  of  ways,  including  x-y  graphs,  bar  graphs,  and  pie  charts.  Additionally,  an 
IBM-done  486-33  microcomputer  is  networked  with  the  Micro  VAX,  allowing  data 
output  in  a  number  of  other  formats,  to  include  ASCII,  SAS,  Lotus,  and  Dbase  Ill-h. 
Turnaround  time  for  hard  copy  data  output  is  4-48  hours,  depending  upon  the  size  of 
the  dataset  and  the  complexity  of  the  processing.  Data  output  can  also  be  exported  via  a 
number  of  media,  including  3-1/2"  and  5-1/4"  diskettes,  1/2"  magnetic  tape,  1/4"  (9- 
track)  tape  cassettes,  8mm  tape  cassettes,  or  90-MB  Bemoullis.  The  site  has  an 
assigned  Research  Analyst  who  provides  test  design  consultation.  The  real-time  data 
analysis  function  is  provided  by  the  Plan  View  Display  and  Stealth  devices,  which  are 
monitored  by  trained  observers.  Such  data  (to  include  full  voice  recording)  can  also  be 
captured  via  in-cockpit  cameras,  FLIR  monitors,  and  non-interactive  playback,  all  of 
which  may  be  recorded  to  VHS  videocassette.  On-site  persoimel  can  additionally 
provide  a  full  spectrum  of  test  design  and  development  and  modeling  consultation 
services. 
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The  ADST  Software  Development  Facility,  shown  in  Figure  2.23-2,  consists  of  four  principal 
laboratories  and  supporting  work  areas,  including: 


Ml  Tank 
Simulator 


BOS-D  Integration  and 
Test  Laboratory 


MCC& 

OIS  Product 

Developinent 

Laboratory 


BDS-D  Classified 

Operations 

Laboratory 


Concurrent 

Engineering 
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SIMNET  M-2  Bradley  Fighting  Vehicle  Simulator,  a  SIMNET  Rotary  Wing  Aircraft 
(RWA)  Simulator;  a  DIS-based  Advanced  Rotary  Wing  Simulator  (ARWA);  and 
SIMNET  Plan  View  Display,  SAFOR,  and  Three  View  Stealth  Displays.  In  addition, 
this  laboratory  also  provides  space  for  computer  systems  used  to  development  both  the 
ARWA  and  Anti- Armor  Advanced  Technology  Demonstration  (A2/ATD)  Delivery 
Orders.  The  I&T  Laboratory  also  contains  the  ADST  Multi-processor  SparcCenter 
2000  Software  Development  Server.  The  I&T  Laboratory  supports  both  E-Net  and 
FDDI  devices. 

b.  PIS  Products  Development  Laboratory.  This  laboratory  is  a  450SF  facility  dedicated  to 
the  development  and  testing  of  DIS  products,  such  as  the  Cell  Adapter  Unit(  CAU), 

Cell  Interface  Unit  (CIU),  ModSAF  and  Protocol  Data  Units  (PDUs).  The  major 
systems  contained  in  this  laboratory  include  a  Sparc  10  computer  running  Cell  Adapter 
Unit  software  used  to  interface  DIS  and  SIMNET  devices;  a  486  PC  computer  running 
DIS  Cell  Interface  Unit  software;  and  a  ModSAF  configuration  hosted  on  an  SGI 
platform. 

c.  Loral  Experimental  and  Developmental  Simulation  (LEADSi  Laboratory.  This 

laboratory,  which  is  approximately  the  same  size  as  the  DIS  Products  Lab,  provides  T- 
1  level  DIS  long  haul  connectivity  with  other  Loral  facilities  such  as  LADS  Cambridge 
and  Bellevue;  WDL,  San  Jose;  Space  and  Range,  Sunnyvale;  Advanced  Projects, 
Reston;  and  Vought  Missile  Systems,  Dallas.  It  is  being  funded  and  equipped  through 
the  Loral  Corporate  LEADS  Coital  project  for  use  as  a  simulation  technology 
development  and  demonstration  facility.  Once  completed,  this  laboratory  will 
complement  and  extend  the  overall  SDF  long  haul  networidng  capability.  i 

d.  Classified  Operations  Laboratory.  This  laboratory  occupies  approximately  1200SF  of  / 

the  SDF  and  provides  the  capability  to  conduct  classified  experiments  through  the  / 

SECRET/Special  Access  level.  Entirely  self-contained,  it  has  its  own  Rber  and  E-N(  / 
networks,  environmental  system,  and  security  system,  and  provides  the  same  level  c  / 
classified  operations  support  as  was  previously  available  in  San  Jose.  / 

e.  System  Fabrication  and  Assembly  Area.  This  area  occupies  approximately  600SF  r  / 

the  SDF  and  provides  space  for  fabrication,  assembly,  and  test  of  simulators  and  th 
subsystems.  This  area  also  provides  component  repair  facilities  and  space  for  SDF  / 
Computer  System  Administration  functions  and  equipment.  / 

f.  Other  SDF  Facilities.  The  SDF  also  contains  space  for  Program  Operations 
Management,  GFE  storage,  shipping  and  receiving  functions,  and  the  facility  ma  / 
electrical  power  supply. 
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Figure  2.2.3. 1 -2.  SDF  Network  EHagram  -  Level  2 
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Figure  2.2.3. 1 -3.  SDF  Fiber  Optic  Network  Distributioo 
2.2.4  Institute  for  Defense  Analysis  (IDA). 

The  ADST  program  supports  the  Institute  for  Defense  Analysis  (IDA)  with  operations  and 
maintenance  support.  The  IDA  facility  is  a  demonstration  site  and  a  development  facility  for 
improving  and  enhancing  distributed  simulation  technology.  A  diagram  of  the  IDA  system 
configuration  is  shown  in  Figure  2.2.4- 1. 
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Figure  2.2.4- 1 .  IDA  Functional  Diagram 
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2.2.5  Interfacing  Sites. 

This  section  discusses  those  sites  which  ADST  either  currently  interacts  or  plans  to  interact 
with. 

2.2.5. 1  MULTIRAD  (Williams  AFB). 

The  MULTIRAD  Delivery  Order  is  an  important  element  of  the  Advanced  EHstributed 
Simulation  Technology  Contract  because  it  provides  for  networiced  extensions  to  Air  Force 
weapon  systems  as  part  of  the  networked  simulation  battlefield  environment.  Elements 
represented  include  both  fixed  wing,  F-16  and  F-15,  Airborne  Radar  AW  ACS,  as  part  of  the 
DoD  networked  simulation  assets.  The  ongoing  Network  Interface  Unit  (NIU)  development  is 
particularly  important  in  interfacing  dissimilar  fidelity  simulators  and  is  a  prototype  for  the  DIS 
Cell  Adapter  Unit  (CAU).  The  linking  of  existing  simulation  assets  utilizing  NIU  capabilities 
is  critical  for  affordable  simulation  network  extensions. 

The  MULTIRAD  Delivery  Order  contains  the  support  of  the  MULTIRAD  Network  and  the 
DMSO  Close  Air  Support  Tasks. 

To  conduct  the  required  multi-ship  training  research,  network  analysis,  and  aid  the 
development  of  simulator  networking  standards,  the  local  area  and  long  haul  MULTIRAD 
network  capability  will  be  improved  and  expanded  at  the  Armstrong  Laboratory  Aircrew 
Training  Research  Division  at  Williams  Air  Force  Base,  AZ.  Figure  2.2.5. 1-1  represents  the 
existing  MULTIRAD  network. 
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Figure  2.2.5. 1  - 1 .  MULTIRAD  Network  Diagram 

2.2.5. 1.1  Network  Interface  Unit  (NIU)  Enhancements. 

A  new  Fiber  Distributed  Data  Interface  (FDDI)  NIU  with  pSOS  operating  system  will  be 
implemented  on  a  token  ring  fiber  optic  Local  Area  Network  (LAN).  To  support  larger 
exercises  with  more  entities  on  the  network,  improvements  to  the  performance  of  the  NIU  will 
be  made.  To  accommodate  devices  that  generate  100  entities  or  more,  and  for  individual 
simulators  to  process  the  data  of  hundreds  of  entities,  parallel  processing,  faster  processors, 
and/or  improved  software  design  will  be  implemented. 

2.2.5. 1.2  Network  Communication  Protocol. 

The  development  of  network  protocol  extensions  to  support  the  research  requirements  of  the 
Air  Force  and  support  the  development  of  DoD/lndustiy  standards  for  Distributed  Interactive 
Simulation  (DIS)  will  continue.  The  NIU  software  complying  with  the  Protocol  Data  Units  for 
Entity  Information  and  Entity  Interaction  in  a  Distributed  Interactive  Simulation  will  be 
developed.  As  the  standard  evolves,  continued  monitoring  of  changes  to  the  standard, 
influencing  modifications  to  the  standard,  and  implementation  of  those  changes  into  the  NIU 
design  will  be  made.  The  goal  is  to  achieve  100%  compatibility  with  all  standards  for  DIS; 
however,  deviations  from  or  extensions  to  the  standard  may  be  implemented  to  meet  the 
MULTIRAD  research  requirements. 
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2.2.5. 1.3  Long  Haul  Network  (LHN). 

In  cooperation  with  DoD  agencies,  the  Defense  Simulation  Internet  (DSI)  and/or  other  wide 
area  networks  to  support  research  requirements  for  long  haul  networking  will  be  used. 

Systems  engineering  for  requirements  analysis,  systems  integration,  specification  generation, 
configuration  management,  network  interface  control,  test  and  evaluation,  and  documentation 
for  any  sites  on  the  LHN  will  be  performed.  The  LHN  will  provide  the  capability  for  multi¬ 
ship  training  evaluation,  network  performance  assessment,  and  protocol  testing  using  a  secure 
LHN. 

2.2.5. 1.4  Close  Air  Support. 

Nodes  for  the  DMSO  Close  Air  Support  effort,  as  agreed  upon  by  the  Air  Force  and  DMSO, 
will  be  established.  The  current  plans  are  to  use  existing  nodes  on  the  DSI  in  combination  with 
dedicated  Tl/KG-94  connections.  The  establishment  of  dedicated  long-haul  connections, 
providing  and  integrating  NIUs,  and  providing  operating  instruction  and  training  to  remote  site 
locations  will  be  provided.  The  sites  are  expected  to  include  a  ground  component,  and  an  air 
component,  a  laser  target  designator,  and  a  command  and  control  component.  Other 
govemment/contractor  sites  are  expected  to  be  added  which  will  require  additional  NIUs  and 
integration  effort. 

2. 2. 5.2  CSRDF  (NASA-Ames). 

The  goal  of  Battlefield  Distributed  Simulation-Developmental  (BDS-D)  is  to  satisfy  the  U.S. 
Army  and  DoD  need  to  conduct  experimental  test  and  analysis  in  support  of  decision-making 
for  force  modernization,  such  as  force  and  organizational  design,  doctrine  and  training 
development,  material  requirements  definition  and  documentation,  operational  testing  and 
evaluation,  and  material  development  and  acquisition. 

A  task  inherent  in  this  goal  is  to  maximize  use  of  existing  and  proposed  engineering  simulators 
and  simulations  by  making  them  interoperable  among  themselves  and  with  BDS-D.  By 
intercoimecting  the  Crew  Station  Research  &  Development  Facilities  (CSRDF)  and  the  A  VTB 
facility  at  Fort  Rucker,  the  issues  related  to  the  linking  of  these  engineering  simulators  and 
BDS-D  simulators  will  be  examined.  Alternative  technical  approaches  will  be  analyzed  and 
solutions  will  be  implemented  compatible  with  the  IDistributed  Interactive  Simulation  (DIS) 
Standard  1.0  of  October  30,  1991.  Distributed  Interactive  Simulation  (DIS)  architectural 
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This  linkage  is  a  cooperative  effort  among  the  U.S.  Army,  DARPA,  and  the  U.S.  Navy.  Each 
is  aggressively  pursuing  interoperable  simulation  as  a  highly  leverage  able  technology  to 
significantly  enhance  combat  readiness  as  well  as  system  acquisition.  Each  has  a  defined  role 
in  this  linkage,  and  success  is  dependent  on  the  cooperation  among  the  three  Government 
groups  and  their  respective  contractors. 

The  CSRDF  /  BDS-D  project  has  two  phases.  Phase  1  is  the  specification  development  and 
linkage  implementation  phase.  After  development  is  completed  and  the  linkage  is  established, 
Rotorcraft  Pilot  Associate  (RPA)  evaluations  will  begin.  Phase  2  is  for  the  testing  with  RWA 
and  for  further  RPA  development.  The  RWA  interface  specification,  design,  and 
implementation  is  included  in  Phase  1 . 

The  following  identifies  those  elements  of  the  CSRDF  (NASA  Ames)  /  BDS-D  (Fort  Rucker/ 
interface  task  that  are  the  responsibility  of  STRICOM  and  are  to  be  executed  by  Loral.  The 
interface  will  provide  several  services. 

a.  Application  Interface  Service.  The  link  will  support  the  real-time  information 
exchange  using  DIS  1.0  between  the  CSRDF  single-mission  simulators  at  NASA 
Ames  and  the  A  VTB  multi-mission  battlefield  simulations  at  Fort  Rucker. 

b.  Network  Protocol  Services.  The  links  will  support  the  Communications  Protocol 
used  to  transport  DIS  Protocol  Data  Units  (PDU)s. 

c.  Long-Haul  Data  Link  Services.  This  provides  the  physical  and  logical  wide  band 
communications  between  sites. 

d.  Correlated  Database.  This  database  contains  terrain  data  and  graphic  models  and  is 
common  between  CSRDF  and  A  VTB. 

e.  Data  Logger.  This  provides  for  recording,  searching,  and  playing  back  packets  that 
flow  across  the  interface. 

The  development  team  includes  STRICOM  and  Loral,  NCCOSC  (Naval  Command,  Control, 
and  Ocean  Surveillance  Center)  Research,  Development,  Test,  and  Evaluation  Division  Navy 
Research  and  Development(NRaD)  and  ETA,  and  U.S.  Army  Aviation  and  Troop  Command 
(ATCOM)  and  CAE,  the  on-site  contractor  at  Crew  Station  Research  and  Development  Facility 
(CSRDF).  Figure  2.2.5 .2-1  illustrates  the  CSRDF/AVTB  connectivity. 
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Figure  2.2.5.2-1.  CSRDF/AVTB  Connectivity  Diagram 
2.3.  Site  Interconnectivity. 

The  Electronic  Information  Exchange  Network  was  established  to  enhance  communication 
between  ADST  and  the  various  communities  (Government,  academic,  and  industrial)  involved 
in  distributed  simulation,  as  well  as  provide  enhanced  communication  between  the  ADST  sites. 

The  Electronic  Information  Exchange  Network  (EIEN)  ECP  has  provided  the  hardware 
infrastructure  which  supports  software  engineering  and  electronic  information  exchange.  The 
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EIEN  has  provided  an  enhanced  method  of  communicating  throughout  major  ADST  sites. 
Figure  2.3-1  illustrates  the  network  interconnectioits  available  to  ADST  and  related  activities. 
This  network  configuration  also  allows  and  enhances  direct  file  transfer,  file  access  and  e-mail 
capability  between  ADST  sites. 


Figure  2.3-1.  Network  Interconnectivity 


2.3.1  ADST  Orlando  Operations  Connectivity. 

As  illustrated  in  Figure  2.3. 1  - 1 ,  the  ADST  office  in  Orlando  has  both  Ethernet  and  AppleTalk 
networks  installed  based  on  Unshielded-Twisted-Pair  (UTP)  wiring.  A  Cabletron  hub 
provides  the  interface  for  both  Ethernet  and  AppleTalk  communications  in  a  single  chassis.  A 
Cayman  Systems  'OatorStar"  provides  connectivity  between  the  AppleTalk  and  Ethernet  for 
both  TCP/IP  and  AppleTalk  protocols.  The  GatorStar  also  provides  file  sharing  via  NFS  to  a 
SUN  SPARCstation  A  Cisco  IR/M  Remote  Protocol  Router  provides  the  Wide  Area  Network 
(WAN)  for  the  TCP/IP  and  AppleTalk  protocols.  A  56Kbps  leased  data  circuit  between  ADST 
PMO  and  Loral  WDL  San  Jose  provides  the  connection  to  the  rest  of  the  EIEN  and  the 
Internet.  The  Cabletron  chassis  provides  802.3  Ethernet  access  as  required  for  TCP/IP  and 
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EtherTalk-based  computer  systems.  An  additicmal  Cisco  MGS  router  is  to  be  installed  to 
support  the  connection  of  1ST  to  the  EIEN. 


56kb  LHN  link  to 
San  Jose 


I 

(modem 


ADST  PMO 
Connectivity 


56kb  LHN  link 
to  1ST 


Figure  2.3. 1  - 1 .  Orlando  ADST  PMO,  EIEN  Connectivity 
2.3.2  San  Jose  Connectivity. 

The  Loral  WDL  San  Jose  node  of  the  EIEN  ccmsist  of  a  Cisco  Systems  AGS+  Multiprotocol 
router.  This  router  connects  to  sites  at  Fort  Rucker,  Fort  Knox,  and  Orlando. 

Z3.3  1ST  Connectivity. 

The  Institute  for  Simulation  and  Training  (1ST)  in  Orlando,  FL  is  connected  to  the  ADST  PMO 
office  in  Orlando  via  a  56Kbps  data  circuit  and  Cisco  MGS  routers.  This  allows  TCP/lP-based 
data  to  be  transferred  directly  without  having  to  traverse  the  Internet. 
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2.3.4  Fort  Rucker,  Fort  Knox  Connectivity. 

The  equipment  provided  to  these  sites  under  the  EIEN  is  shown  in  Figures  2.3.4- 1  and  2.3.4- 
2.  Fort  Rucker  and  Fort  Knox  are  connected  to  Loral  WDL  San  Jose  via  56Kbps  leased  data 
circuits  and  Cisco  routers.  This  allows  TCP/IP  and  AppleTalk-based  data  to  be  transferred 
directly  without  having  to  traverse  the  Internet.  A  Cayman  Systems  GatorBox  CS  at  each  site 
allows  AppleTalk-based  traffic  to  pass  to  the  sites'  Ethernet  and  then  on  to  the  WAN  for 
transmission  on  the  EIEN. 
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Figure  2.3.4- 1.  Fort  Knox  MWTB,  EIEN  Connectivity 
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Figure  23.4-2.  Fort  Rucker  AVTB,  EIEN  Connectivity 
3  SOFTWARE. 

At  the  start  of  the  second  contract  year,  the  BDS-D  system  consisted  of  the  application  software 
and  data  that  was  running  at  the  two  BDS-D  sites.  Fort  Knox  and  Fort  Rucker  (formally 
known  as  SIMNET  D-Sites).  The  only  source  code  that  was  available  was  ftom  the 
STRICOM  SIMNET  library.  This  source  code  was  incomplete  and  not  the  version  running  at 
any  of  the  sites.  Under  the  DARPA  SIMNET  Bridge  Contract  with  BBN,  a  set  of  Software 
Design  Documents,  a  complete  set  of  source  code  and  utilities,  and  a  complete  set  of  cold  start 
procedures  were  scheduled  to  be  delivered.  This  effort  was  terminated  prior  to  the  completion 
of  these  tasks.  A  set  of  Software  Design  Documents  was  delivered  in  June  1991.  However, 
this  set  of  documents  reflected  SIMNET  Release  6.6.0  and  not  SIMNET  6.6.1,  which  was 
fielded  to  the  SIMNET  T-sites  in  early  1991.  No  source  code  or  code  start  procedures  were 
delivered. 

a.  Documentation.  Table  3-1  lists  the  SIMNET  6.6.0  Software  Design  Documents.  As 
mentioned,  this  documentation  set  reflects  SIMNET  Version  6.6.0  and  not  SIMNET 
Version  6.6.1  that  is  currently  fielded.  Therefore,  system  additions  and  software 
problems  fixed  between  Version  6.6.0  and  6.6. 1  are  not  reflected  in  this  documentation 
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set.  The  major  differences  between  these  versions  are  the  addition  of  the  Dismounted 
Infantry  Simulator  and  the  addition  of  Combat  Engineers  to  the  MCC. 

Also,  those  SIMNET  elements  that  were  only  fielded  to  the  SIMNET  D-Sites  were  not 
considered  part  of  the  formal  SIMNET  Version  6.6.1  release.  Therefore,  no  Software 
Design  E)ocuments  exist  for  RWA,  FWA,  NLOS,  FAAD,  RWA  CTAS  extensions, 
AVTB  MCC,  SINCGARS,  CVCC,  M1A2,  or  any  other  software  that  was  developed 
for  a  particular  test  or  experiment.  While  NLOS  design  documentation  is  not  available, 
source  code  is  available.  The  Ml  A2  simulators  were  developed  by  General  Dynamics 
Land  Systems  (GDLS)  and  no  source  code  or  software  documentation  is  available. 
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Table  3- 1 .  SIMNET  6.6.0  Software  Design  Documents 


m\ 

NUMBER 

hmmwwm - 

1 

Software  Design  Document  MCC  CSCI  (1) 

Volume  1  of  2  Sections  l.O -  2.18 

1 

Software  Design  Document  MCC  CSCI  (1) 

Volume  2  of  2  Section  2.18.1  -  2.22 

2 

Software  Design  Document  NOM  CSCI  (2) 

3 

Software  Design  Document  PVD  CSCI  (3) 

Volume  1  of  2  Sections  1.0  -  2.1 1.3.1 

5 

Software  Design  Document  PVb  (3) 

Volume  2  of  2  Appendices 

4 

Software  Design  Document  DL  CSCI  (4) 

5 

Software  Design  Document  Vehicle  Simulation  CSCI  (5) 

Volume  1  of  4  Sections  1.0  -  2.2.3. 1 

5 

Software  Design  Document  Vehicle  Simulation  CSCI  (S) 

Volume  2  of  4  Sections  2.2.3.2  -  2.5.3.27.1 

5 

Software  Design  Document  Vehicle  Simulation  CSCI  (5) 

Volume  3  of  4  Sections  2.5.4  -  2.6.18.12.1 

5 

Software  Design  Document  Vehicle  Simulation  CSCI  (5) 

Volume  4  of  4  Appendices 

6 

Software  Design  Document  SAP  Woilcstation  CSCI  (6) 

Volume  1  of  2  Sections  1 .0  -  2.4.3.86 

6 

Software  Design  Document  SAP  Woilcstation  CSCI  (6) 

Volume  2  of  2  Sections  2.4.3.4.87  -  2.9.7  and  Appendices 

7 

Software  Design  Document  SAP  Parameter  Editor  CSCI  (7) 

8 

Software  Design  Document  SAP  Simulation  Host  CSCI  (8) 

Volume  1  of  2  Sections  1 .0  -  2.7 

8 

Software  Design  Document  SAP  Simulation  Host  CSCI  (8) 

Volume  2  of  2  Sections  2.7.1  -  2.15 

9A 

Software  Design  Document  CIG  Host  CSCI  (9A) 

9B 

Software  Design  Document  GT  Real-Time  Software  Host  CSCI  (9B) 

Volume  1  of  2  Sections  1.0-2.12.19.2 

9B 

Software  Design  Document  GT  Real-Time  Software  Host  CSCI  (9B) 

Volume  2  of  2  Sections  2. 12.20  -  3.2  and  Appendices 

Table  3-2  describes  the  version  of  each  CSCI  as  it  relates  to  SIMNET  Version  6.6.1. 

Table  3-3  describes  the  current  version  each  CSCI  that  was  not  part  of  the  formal  SIMNET 
Version  6.6. 1  release. 
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b.  Source  Code.  Since  the  implementation  of  the  Software  CCP  to  the  LSE  in  June  1992, 
Loral  has  been  developing  Version  Description  Documents  (VDDs),  Cold  Start 
Procedures  (CSPs),  and  certain  other  documentation  useful  to  the  customer  and 
engineering  communities  in  understanding  and  using  SIMNET  code  for  current 
developmental  and  experimental  purposes.  The  CCP  effort  also  provides  fully 
baselined  and  configuration  managed  source  and  executable  code  for  distribution  to  the 
DIS  community.  A  more  detailed  discussion  of  the  ADST  Configuration  Management 
(CM)  process  and  current  status  of  the  ECP  software  baselining  and  documentation 
effort  is  provided  in  Section  4.1. 

Through  the  Software  Support  CCP,  the  SIMNET  source  code  was  delivered  to 
ADST.  The  initial  delivery  of  software  is  summarized  in  Table  3-4.  The  source  code 
was  delivered  on  150MB  1/4"  cartridge  tapes,  with  the  exception  of  the  MCC 
Macintosh  workstation  source  code,  which  is  on  3  1/2"  DS,  DD  diskettes. 
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Table  3-4.  Initial  Source  Code  Delivery 


DISKETT 

E 


Tape  4 


Tapes 


Tapes 


Tape  9 


Tape  1 


Tape  1 1 


Tape  12 


Tape  13 


Tape  14 


Tape  17 


Tape  18 


Tape  21 


Tape  22 


Tape  23 


Tape  24 


Tape  2 


Tape  27 


Tape  31 


Tape  32 


Lhskette 


Ehskette 


Tape  34 


Tape  37 


Diskette 


_gt4.7  for  gt  release 


Knox3cow.(X)l  -  Database 


gt-ielease  M2-applicauon  _ 


.1  Dl-application _ 


gt-release  6.6. 1  Stealth-application _ 


.1  Ml -application 


ource  for  MCC  release  6.5.3  part  o 


Sources  for  MASSCOMP  release  6.6.1  contains-Ml  and  Stealth 


Sources  for  gt  release  of  6.6. 1  contains  -  Dl,  Ml,  M2,  and  Steal 


Release  6.6. 1  Logger  src  _ 


PVD  Source  release  for  6.6.1  pvd/common  Tape  1  o 


PVD  Source  release  for  6.6.1  pvd/siinnet  pvd/tmp  Tape  2  o 


MCC  release  6.6.1  MCC  Version  6.5.3 


Datalogger  release  6.6.1  Make  install_appl 


Masscomp  Ml  release  6.6.1 /delta/simnet  Includes  CIG  software _ 


A  VTB  FWA  and  RWA  applicati«i  tape _ 


AVTB  FWA  and  RWA  sources  (Made  on  Sun) 


Boot  tape  gtos4.7 


AF  Source  code  3.1 


AF  Coldstait  comment  source  tape 


SAF  Coldstait  Application  source  tape 


SAP  Coldstart  Terram  Datarase  tape  (Knox) 


AF  Coldstart  Application  Tape  _ 


AF  Coldstart  System  Tape  _ 


SAF  Coldstart  FfciP  tape  1  ((3eneva-7-2-color)  _ 


SAF  Coldstart  FEP  Tape  2  (Geneva-7-2-color) _ 


AF  Coldstart  Distnbution  Tape  1  (Knox-terram  system) 


SAF  Coldstart  Cany  Dump  tape _ _ 


SAF  Coldstart  Distnbution  Tape  1  (map  &  saf  system) 


CVCC  -  gt  -  release  includes  -  data  files  _ 


CVCC  -  CITV  source  release 


PVD  release  6.6. 1  mcludes  -  data  files 


MCC  6.5.3  (Total  of  3  diskettes)  MAC  Sources 


MCC  6.5.3  (Total  of  8  diskettes)  for  MAC 


M2  6.6.1  application  tape  including  Butterfly  Operating  System  and  Tools 


M2  Butterfly  _ 


ibipc  _ 


Missmg  Mac  files  
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The  source  code  and  documentation  are  part  of  the  ADST  Technical  Library. 
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Since  the  implementation  of  the  ADST  contract  s*'.d  initiation  of  the  SWCCP,  a  significant 
number  of  both  SIMNET  and  DIS-based  software  products  have  been  developed.  In  some 
cases,  such  as  the  Data  Logger,  both  SIMNET  and  DIS  products  now  exist.  Also,  with  the 
introduction  of  new  hardware  platforms  at  the  ADST  sites,  versions  of  a  number  of  these 
software  products  have  been  rehosted  to  run  on  the  newer  platforms,  particularly  SGI  and 
SUN.  The  following  section  contains  a  brief  discussion  of  each  Computer  Software 
Configuration  Item  (CSCI).  Since  formal  configuration  management  has  not  been 
completed,  the  CSCI  descriptions  are  based  primarily  on  those  given  in  the  Software 
Design  Document  documentation  set  (refer  to  Table  3.1). 

3.1  Data  Logger  (DL). 

3.1.1  Description. 

The  Data  Logger  (Figure  3. 1 . 1  - 1 )  is  a  network  management  tool  that  captures  the  events  of  an 
exercise  run  over  the  network  by  recording  Protocol  Data  Units  (PDUs)  sent  by  all  network 
participants.  An  exercise  can  then  be  replayed  from  the  information  captured  by  the  Data 
Logger.  There  are  different  versions  of  the  Data  Logger  for  both  SIMNET  and  DIS  protocols. 


Data  Logger 

Lt- 

SIMNET  or  DIS  NETWORK 


(Masscomp  host 
SUN  host 
SGI  host 
MIPS  host 


Figure  3. 1 . 1  - 1 .  Data  Logger  Diagram 

3.1.2  Documentation. 

a.  Cold  Start  Procedure  (CSPl  for  the  Data  Logger  (TR-93-(X)3074). 

b.  Version  Description  Document  (VDD)  for  the  Data  Logger  (TR-93-(X)3073). 
d.  Software  Design  Document  for  the  Data  Logger  CSCI  (June  1991). 

c.  The  Logger  Interface  User  Guide  (ModS AF). 
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3.1.3  Software. 

a.  Masscomp  Real  Time  UNIX  (RTU)  Version  4.0A, 

b.  BDS-D  Data  Logger  1.0.0  Source  and  Runtime  Files  (SIMNET,  Masscomp  host). 

c.  BDS-D  Data  Logger  1 .2.0  Source  and  Runtime  Files  (DIS,  Masscomp  host). 

d.  ModSAF  1 .0  Data  Logger  Source  and  Runtime  Files  (DIS  or  SIMNET,  SGI  and 
MIPS  hosts). 

e.  Logger  6.6.S  Source  and  Runtime  Files  (DIS,  SUN,  SGI.and  Masscomp  hosts). 

f.  Logger  6.6.4  Source  and  Runtime  Files  (SIMNET,  SUN,  SGI,and  Masscomp  hosts). 

g.  Architecture  &  Standards  (AS)  Data  Ix)gger  Source  and  Runtime  Files  (DIS,  SGI 
host). 

3.1.4  Computer  Software  Configuration  Item  (CSCl)  Breakdown. 

a.  Libraries  Computer  Software  Component  (CSC). 

b.  Data  Logger  Files  CSC. 

3.2  Digital  Message  Communication  Console  (DMCC). 

3.2.1  Description. 

The  DMCC  (Figure  3.2. 1-1)  allows  transmission,  reception,  storage  of,  and  access  to,  pre¬ 
formatted  and  free  text  tactical  messages  between  Ground  Support,  Tactical  Operations 
Centers,  Fire  Support  Elements,  and  manned  Vehicle  Simulators,  via  the  SIMNET  and  DIS 
simulation  networks.  The  DMCC  uses  graphical  user  interfaces  to  emulate  vehicle  crew  station 
soldier  machine  interfaces.  Up  to  eight  X-terminals  may  be  coimected  to  the  server 
woricstation  via  a  dedicated  Ethernet  local  area  networks 
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Figure  3.2. 1- 1 .  Digital  Message  Communication  Console  (DMCC)  Diagram 

3.2.2  Documentation. 

a.  Software  Maintenance  Manual  (SMM)  for  the  DMCC  (TR-93-003062). 

b.  Cold  Start  Procedure  (CSP)  for  the  DMCC  rrR-93-003047V 

c.  Operations  Manual  (OPS)  for  the  DMCC  rrR-93-(X)3054A). 

d.  Version  Description  Document  (YDD)  for  the  DMCC  rrR-93-(X)30461 

e.  Sof  are  Design  Document  (SDD)  for  the  DMCC  SCSI  rrR-93-003036). 

3.2.3  Software. 

a.  BDS-D  DMCC  1 .0.0  Source  and  Runtime  Files. 

b.  XI 1  Release  5  Windowing  System. 

c.  Motif  Version  1.1.3. 

d.  SUNOS  4.1.1. 

3.2.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  dms  Computer  Software  Component  (CSC). 

b.  build  pdu  CSC. 

c.  ipc  CSC. 
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d.  etheraetCSC. 

e.  client  CSC. 

3.3  Ml  /  M2  /  STEALTH  Simulators. 

3.3.1  Description. 

A  vehicle  simulator  is  composed  of  one  or  more  crewstations.  Each  crewstation  provides  the 
subset  of  controls  and  indicators  that  would  be  available  to  that  specific  crew  member  on  the 
actual  vehicle.  A  critical  element  of  each  crewstation  is  the  out-the-window  view,  or  vision 
block  associated  with  the  station.  These  provide  the  crew  member  with  a  three  dimensional 
graphical  representation  of  the  terrain  and  objects  in  the  environment  external  to  the  vehicle. 
The  purpose  of  the  vehicle  simulation  software  (Figure  3.3. 1-1)  is  to  maintain  the  vehicle 
specific  model,  respond  to  crew  inputs,  update  crewstation  outputs,  and  communicate  with  the 
network.  The  vehicle-specific  model  includes  the  mathematical  model  of  the  drivetrain,  power 
plant,  suspension,  weapons  systems,  and  other  internal  systems  necessary  to  compose  the 
vehicle  entity.  These  systems  that  are  modeled  have  their  corresponding  operator  interfaces  in 
the  crewstations.  The  crewstation  outputs  include  the  local  sound  system  and  the  updates  to 
the  Computer  Image  Generator  (CIG),  which  presents  the  three  dimensional  image  in  the 
vision  blocks.  Though  it  may  be  composed  of  several  individual  crewstations,  the  vehicle 
simulation  represents  a  single  entity  on  the  network,  and  interacts  with  other  network  entities 
via  the  network  interface. 
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Figure  3.3. 1-1.  Ml  /  M2  /  Stealth  Simulator  Diagram 
3.3.2  Documentation. 

a.  Software  Design  Document  for  the  Vehicle  Simulation  CSCI  (Volumes  1  through  4, 
June  1991). 

b.  Software  Design  Document  for  the  CIG  Host  CSCI  (June  19911. 

c.  Software  Design  Document  for  the  GT  Real-Time  Software  Host  CSCI  (Volumes  1 
and  2,  June  1991). 

d.  Version  Description  Document  (VDDi  for  the  GT-Ml  rrR-92-003032). 

e.  Cold  Start  Procedure  (CSP)  for  the  GT-Ml  rrR-92-003033Al. 

f .  Version  Description  Document  (VDDi  for  the  Ml/XROD  (TR-93-()03030). 

g.  Cold  Start  Procedure  (CSP)  for  the  Ml/XROD  rrR-92-()03031Ai. 

h.  Version  Description  Document  (VDDi  for  the  Masscomp-Ml  rrR-93-(X)3()66J. 

i.  Cold  Start  Procedure  (CSP)  for  the  Masscomp-Ml  rrR-93-()03072). 

j .  Version  Description  Document  (VDDi  for  the  VIDS-GT-Ml  (Draft). 

k.  Cold  Start  Procedure  (CSP)  for  the  VIDS-GT-Ml  (Draft). 

l.  Operation  Manual  (OPSl  for  the  VIDS-GT-Ml  (Draft). 
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3.3.3  Software. 

a.  GT  rtt  5.7  Visual  System  Software. 

b.  GTOS  4.7  Operating  System. 

c.  GT  6.6.1  MI  Source,  Application,  and  Runtime  Files. 

d.  GT  6.6.1  M2  Source,  Application,  and  Runtime  Files. 

e.  GT  6.6.1  Stealth  Source,  Application,  and  Runtime  Files. 

f .  Terrain  Databases. 

g.  BDS-D  Ml  1 .0.0  Source,  Application,  and  Runtime  Files. 

h.  Masscomp  Real  Time  UNIX  RTU4.0A. 

i .  BDS-D  M 1/XROD  1 .0.0  Source,  Application,  and  Runtime  Files. 

j .  BDS-D  VIDS  Source,  Application,  and  Runtime  Files. 

k.  DOS  5.0. 

3.3.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  Device  Interfaces  Computer  Software  Component  (CSC). 

b.  Ml  Vehicle  Simulation  Functions  CSC. 

c.  M2  Vehicle  Simulation  Functions  CSC. 

d.  Stealth  Vehicle  Simulation  Functions  CSC. 

e.  Vehicle  Libraries  CSC. 

f .  Simulation  Support  Utilities  CSC. 

3.4  Combat  Vehicle  Command  and  Control  (CVCC). 

3.4.1  Description. 

The  CVCC  (Figure  3.4. 1-1)  is  a  Ml  tank  simulator  which  has  been  modified  to  test  several 
future  tank  design  concepts  and  features.  The  CVCC  incorporates  a  position  navigation 
system,  a  commander's  independent  thermal  viewer ,  a  thermal  sight  channel  for  the  gunner, 
and  an  updated  version  of  the  Inter-Vehicular  Information  System  (IVIS). 
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3.4.2 

a. 

b. 

c. 

d. 

3.4.3 

a. 

b. 

c. 

d. 

e. 

f. 


SIMNET  NETWORK 


Figure  3.4. 1  - 1 .  Combat  Vehicle  Command  and  Control  (CVCC)  Diagram 
Documentation. 

Cold  Start  Procedure  (CSP)  for  the  CVCC  (TR-93-00321 1). 

Version  Description  Document  (VDDl  for  the  CVCC  (TR-93-003 1 2). 

SIMNET  Combat  Vehicle  Command  and  Control  (CVC21  System  (December  1990). 
SIMNET  CVCC  IVIS  Utilities  User  Manual  (July  1991). 

Software. 

SUNOS  Version  4.1.2. 

SUN  OpenWindows  3.0. 

ICS  Motif  Version  1.1.3. 

GNU  gdbm  Version  1.5. 

BDS-D  CVCC  Source,  Applications,  and  Runtime  Files. 

Terrain  Databases. 
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3.5  Protocol  Translator  (PT). 

3.5.1  Description. 

The  Protocol  Translator  (PT)  (Figure  3.5. 1-1)  supports  interoperability  between  SIMNET  and 
DIS  1 .0  simulation  exercises  within  the  constraints  of  translated  PDUs.  The  PT  consists  of 
two  parallel  processes,  the  DlS-to-SlM  translator  and  the  SlM-to-DIS  translator.  The  DlS-to- 
SIM  translator  receives  DIS  1 .0  UDP  datagrams  from  the  designated  DIS  ethemet  interface  and 
sends  the  translated  datagrams  in  SIMNET  format  to  the  SIMNET  network  through  the 
designated  SIMNET  ethemet  interface.  The  SlM-to-DIS  translator  receives  SIMNET  PDUs 
from  the  designated  SIMNET  ethemet  interface  and  sends  the  translated  PDUs  in  DIS  1 .0 
format  to  the  DIS  network  through  the  designated  UDP  port 


Protocol 

Translator 


DIS  1 .0  NETWORK 


SIMNET  NETWORK 

Figure  3.5. 1  - 1 .  Protocol  Translator  (PT)  Diagram 
3.5.2  Documentation. 

a.  Software  Maintainance  Manual  (SMM)  for  the  PT  rrR-93-003064). 

b.  Interface  Requirements  Specification  (IRS)  for  the  PT  (TR-93-003065). 

c.  Version  Description  Document  (VDD)  for  the  PT  (TR-93-(X)3213). 

d.  Cold  Start  Procedure  (CSP)  for  the  PT  (TR-93-003214). 

e .  Software  Design  Document  (SDD)  for  the  PT  (TR-93-00307 1 ). 

f.  Software  Requirements  Specification  (SRS)  for  the  PT  (June  1992). 
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3.5.3  Software. 

a.  BDS-D  PT  2.0.0  Source  and  Runtime  Files. 

b.  SUNOS  4.1.1. 

c.  Openwindows  3.0. 

d .  Gcc  C  Compiler  Version  1 .4  (or  higher). 

3.5.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  SIMNET  Network  Interface  Process  Computer  Software  Component  (CSC). 

b.  DIS  Network  Interface  Process  CSC. 

c.  SIMNET  to  DIS  Format  Translation  Process  CSC. 

d.  DIS  to  SIMNET  Format  Translation  Process  CSC. 

e .  Dead  Reckoning  CSC. 

3.6  Plan  View  Display  (PVD). 

3.6.1  Description. 

The  PVD’s  (Figure  3.6.1-1)  function  is  to  provide  a  map-based  “God’s  eye  view”  of  one  or 
more  distributed  simulation  exercises.  The  PVD  can  display  the  entire  terrain  database  or 
selected  regions  via  menu  selection.  Vehicles  in  the  distributed  simulation  are  represented  by 
small  icons  that  show  the  vehicle  location  and  hull/tunet  orientation.  Intervisibility  between 
vehicles  on  the  terrain  can  be  displayed.  The  PVD  can  remotely  control  both  the  data  logger 
and  the  stealth  vehicle. 


Masscomp 

Hosted 

PVD 

_±_ 

SIMNET  NETWORK 


Figure  3.6. 1-1.  Plan  View  Display  (PVD)  Diagram 
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3.6.2  Documentation. 

a.  Cold  Start  Procedure  fCSP)  for  the  PVD  rrR-93-003077). 

b.  Version  Description  Document  (VDD)  for  the  PVD  rrR-93-QQ3076i. 

c.  Software  Design  Document  for  the  PVD  CSCl  (Volumes  1  and  2,  June  1991). 

3.6.3  Software. 

a.  PVD  1 .0.0  Source  and  Runtime  Files. 

b.  Masscomp  Real  Time  UNIX  (RTU)  Version  4.0A. 

3.6.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  Menu  Handling  Computer  Software  Component  (CSC). 

b.  Icons  CSC. 

c.  Map  Handling  CSC. 

d.  PVD-Level  Processing  CSC. 

e.  Utilities  CSC. 

f.  Network  Processing  CSC. 

g.  Graphics  CSC. 

h.  Overlays  CSC. 

i.  Popup  Windows  CSC. 

j.  Tools  CSC. 

k.  Remote  Devices  Interfaces  CSC, 

3.7  Semi-Automated  Forces  (SAF). 

3.7.1  Description. 

The  Semi- Automated  Forces  (SAF)  systems  (Figure  3.7. 1-1)  provide  a  means  of  incorporating 
intelligent,  realistic  participants  not  requiring  a  vehicle  simulation  into  a  network  battle  exercise. 
It  is  typically  partitioned  across  several  processing  platforms,  the  minimal  configuration  usually 
being  a  vehicle  simulation  processor  and  a  Graphical  User  Interface  (GUI)  processor.  There 
are  currently  three  SAF  systems  available:  the  SIMNET  SAF  system,  the  Order  of  Battle 
Generator  (OBG)/SAF  system,  and  the  Modular  SAF  (ModSAF)  system. 
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Figure  3.7. 1-1 .  Semi- Automated  Forces  (SAF)  Diagram 

3.7.2  Documentation. 

3.7.2. 1  SIMNET  SAF. 

a.  Software  IDesign  Document  for  the  SAF  Workstation  CSCI  (Volumes  1  and  2,  June 
1991). 

b.  Software  Design  Document  for  the  SAF  Parameter  Editor  CSCI  f  June  19911. 

c.  Software  Design  Document  for  the  SAF  Simulation  Host  CSCI  (Volumes  1  and  2, 
June  1991). 

3. 7. 2. 2  OBG/SAF. 

a.  The  OBG/SAF  Interface  Version  4.3.3  User  Guide. 

b.  Notes  for  SAF  Version  4.3.3  Release. 

3. 7. 2. 3  ModSAF. 

a.  ModSAF  User  Manual  Version  1.0. 

b.  ModAF  1 .0  Release  Notes. 

3.7.3  Software. 

3. 7. 3.1  SIMNET  SAF. 

a.  Geneva  7.2  OS. 

b .  SIMNET  SAF  Version  3. 1 1 .2  Source  and  Runtime  Files. 

c.  Terrain  Database. 
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3. 7. 3. 2  OBG/SAF. 

a.  OBG/SAF  4.3.3  Source  and  Runtime  Files. 

b.  Tenain  Database. 

3. 7. 3. 3  ModSAF. 

a.  ModSAF  Version  1 .0  Source  and  Runtime  Files. 

b.  Terrain  Database. 

3.7.4  Computer  Software  Conflguration  Item  (CSCI)  Breakdown. 

3.7.4. 1  Graphical  User  Interface  (GUI). 

a.  User  Process  CSC. 

b.  Commander  CSC. 

c.  Battlemaster  CSC. 

d.  Map  Display  CSC. 

e.  World  State  CSC. 

f.  SAF  Command  Protocol  Interface  CSC. 

g.  Global  CSC. 

h.  Utilities  CSC. 

i.  Compilation  and  Installation  CSC. 

3. 7. 4. 2  Parameter  Editor. 

a.  Model  Editor  CSC. 

b.  Weapons  Systems  Editor  CSC. 

c.  Formations  Editor  CSC. 

3. 7. 4. 3  SAF  Simulation. 

a.  Initialization  CSC. 

b.  Scheduler  CSC. 

c.  Network  Interface  CSC. 

d .  SAF  Command  Interface  CSC. 

e.  Parser  Interface  CSC. 

f.  Local  Vehicles  CSC, 
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g.  Remote  Vehicles  CSC. 

h.  Remote  Vehicles  CSC. 

i.  Units  CSC. 

j.  SAP  Objects  CSC. 

k.  OPORDERSCSC. 

l.  Create  CSC. 

m.  Terrain  CSC. 

n.  Global  CSC. 

o.  Utilities  CSC. 

p.  Support  CSC. 

3.8  Rotary  Wing  Aircraft  (RWA)  Simulator. 

3.8.1  Description. 

The  Rotary  Wing  Aircraft  (RWA)  (Figure  3.8.1-1)  simulates  a  manned  flight  vehicle  and 
associated  weapons  systems  for  conducting  simulated  missions  within  a  controlled  database 
and  tactical  environment.  The  RWA  operates  on  the  same  principles  as  a  ground  vehicle 
simulator.  It  contains  a  CIG  for  generating  three-dimensional  “out-of-the-cockpit”  imagery  to 
be  displayed  using  either  monitors  or  projectors.  It  provides  the  appropriate  controls  and 
indicators  for  each  of  the  flight  crew.  A  simulation  host  within  the  simulator  maintains  a  flight 
model  of  the  RWA  and  interacts  with  the  crewstation  control  systems  and  CIG. 
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Figure  3.8. 1  - 1 .  Rotary  Wing  Aircraft  (RWA)  Diagram 

3.8.2  Documentation. 

a.  Cold  Start  Procedure  (CSP)  for  the  RWA/Aimet  (TR-93-(X)3028A). 

b.  Version  Description  Document  (VDD^  for  the  RWA/Aimet  rrR-93-Q03066). 

3.8.3  Software. 

a.  GT  rtt  5.7  Visual  System  Software. 

b.  GTOS  4.7  Operating  System. 

c.  BDS-D  RWA  1 .0.0  Source,  Application,  and  Rimtime  Files. 

3.9  Computer  Image  Generator  (CIG). 

3.9.1  Description. 

A  Vehicle  Simulator  consists  of  a  CIG  (Figure  3.9.1-1),  a  simulation  host,  one  or  more  display 
monitors,  a  user,  and  the  user’s  control  mechanisms.  Each  simulator  simulates  the  actions  of 
one  combat  vehicle  in  real  time.  The  CIG  controls  the  images  in  the  simulation  viewports 
(displays),  and  houses  the  database  that  describes  the  simulation  terrain.  The  CIG  can  contain 
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Figure  3.9.1  -1.  Computer  Image  Generator  (CIG)  Diagram 

a.  AT  backend  generates  up  to  eight  low-resolution  (320  by  200  pixels)  views.  These 
views  are  used  in  the  Ml  and  M2  Simulators. 

b.  A  TX  backend  generates  one  high-resolution  (640  by  480  pixels)  view  or  two  low- 
resolution  (320  by  240  pixeL;  views.  These  views  are  used  in  the  Stealth  Simulators. 

The  GTlOl  is  equivalent  to  the  earlier  120T  CIG.  The  GTl  10  is  equivalent  to  the  earlier 
120TXCIG. 

3.9.2  Documentation. 

a.  Software  Etesign  Document  for  the  CIG  Host  CSCI  (June  1991). 

b.  Software  Design  Document  for  the  GT  Real  Time  Software  Host  CSCI  (June  1991). 

3.9.3  Software. 

a.  GTrtS.S. 

b.  GTOS  4.5  (used  on  CVCC  simulator  at  Fort  Knox). 
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c.  GTOS4.7. 

d.  GT  6.6. 1  Source  and  Runtime  Files. 

e.  GT  6.6.1  Stealth  Application. 

f.  GT  6.6.1  Ml  Source  Files  and  Application. 

g.  GT  6.6. 1  M2  Source  Files  and  Application. 

h.  GT6.6.1D1  Source  Files  and  Application. 

i.  Tenain  Database. 

3.9.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  Task  Initialization  CSC. 

b.  CIG  Host  Mainline  CSC. 

c.  Database  Management  CSC. 

d.  Database  Feedback  CSC. 

e.  Ballistics  Processing  CSC. 

f.  User’s  Interface  CSC. 

g.  Stand-Alone  Message  Interface  CSC. 

h.  Force  Processor  Task  CSC. 

3.10  Vehicle  Integrated  Defense  System  (VIDS). 

3.10.1  Description. 

The  VIDS-equipped  Ml  Tank  Simulator  (Figure  3.10.1-1)  exists  to  support  a  series  of 
survivability  experiments.  The  nature  of  the  experiments  requires  that  the  VIDS  simulatitm  be 
parameter-driven.  The  VIDS  parameters  not  only  define  available  sensors  and 
countermeasures,  but  also  define  their  respective  sensitivities  and  response  times.  The  VIDS 
Ml  simulator  and  its  associated  PC  communicate  with  each  other  over  the  SIMNET  using  a 
custom  protocol.  For  the  present,  eight  sensors  and  nine  countermeasures  are  simulated.  The 
sensors  simulated  are  the  Laser  Warning  Receiver  (LWR),  Missile  Warning  System  (MWS), 
Future  Armored  System  Radar  (FASR),  Seismic  Mine  Sensor,  Non-Imaging  System  (NIS), 
Tank  Radar  Warning  Receiver  (TRWR),  Muzzle  Flash  Detector  (MFD),  and  a  Nuclear 
Chemical  Sensor  (NCS).  The  countermeasures  simulated  are  the  Multi-Salvo  Smoke  Grenade 
Launcher/Rapid  Obscuration  System  (ROS),  Missile  Countermeasure  Device  (MCD),  Combat 
Protection  System  (CPS),  Laser  Countermeasure  Device  (LCMD),  Vdiicle  Magnetic  Signature 
Duplication  (VEMASID),  Nuclear  Biological  Chemical  Overpressure  (NBCOP),  Advanced 
Threat  Radar  Jammer  (ATRJ),  Threat  Countermeasure  System  (TCS),  and  ChafEnares. 
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Figure  3. 10. 1  - 1 .  Vehicle  Integrated  Defense  System  (VIDS)  Diagram 

3.10.2  Documentation. 

a.  Software  Design  E)ocument  for  the  Vehicle  Simulation  CSCI  (Volumes  1  through  4, 
June  1991). 

b.  Software  Design  Document  for  the  CIG  Host  CSCI  (June  19911. 

c.  Software  Design  Document  for  the  GT  Real-Time  Software  Host  CSCI  (Volumes  1 
and  2,  June  1991). 

d.  Version  Description  Document  (VDD)  for  the  GT-Ml  rrR-92-003Q321. 

e.  Cold  Start  Procedure  (CSP)  for  the  GT-Ml  (TR-92-003033A). 

f .  Version  Description  Document  (VDD)  for  the  Ml/XROD  (TI''>-93-(X)3030). 

g.  Cold  Start  Procedure  (CSP)  for  the  Ml/XROD  rrR-92-003031Al. 

h.  Version  Description  Document  (VDD)  for  the  Masscomp-Ml  (TR-93-003066). 

i.  Cold  Start  Procedure  (CSP)  for  the  Masscomp-Ml  (TR-93-(X)3072). 

j.  Version  Description  Document  (VDD)  for  the  VIDS-GT-Ml  (Draft). 

k.  Cold  Start  Procedure  (CSP)  for  the  VIDS-GT-Ml  (Draft). 

l.  Operation  Manual  (OPS)  for  the  VIDS-GT-Ml  (Draft). 

3.10.3  Software. 

a.  GT  rtt  5.7  Visual  System  Software. 

b.  GTOS  4.7  Operating  System. 

c .  GT  6.6. 1  M 1  Source  Files  and  Application. 

d.  Terrain  Databases. 

e .  BDS-D  M 1  1 .0.0  Source,  Application,  and  Runtime  Files. 

f .  Masscomp  Real  Time  UNIX  RTU4.0A. 

g.  BDS-D  Ml/XROD  1.0.0  Source,  Application,  and  Run  ,es. 
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h.  BDS-D  VIDS  Application. 

i.  DOS  5.0. 


3.10.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  VIDS- GT  CSC. 

b.  VIDS-PCCSC. 

3.11  Masscomp  Hosted  Management  Command  and  Control  (MCC). 
3.11.1  Description. 

The  MCC  System  (Figure  3. 1 1 . 1- 1)  is  used  in  setting  up  simulations  and  simulating  elements 
of  the  battlefield  environment.  It  tracks  the  condition  of  the  various  manned  simulators  for 
which  it  is  responsible,  as  well  as  vehicles  that  it  generates  for  service  and  repair.  The  MCC 
also  handles  various  aspects  of  minelaying  and  monitors  the  availability  of  fuel  and 
ammunition. 
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Figure  3.11.1-1.  Masscomp  Hosted  Management  Command  and  Control  (MCC)  Diagram 
3.11.2  Documentation. 

a.  Software  Maintenance  Manual  (SMM)  for  Masscomp  hosted  MCC  ny-93-(X)3Q63Ay 
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^  Cold  Start  Procedure  (CSP)  for  Masscomp  hosted  MCC  (TR-93-(X)3043). 

c.  Operations  Manual  (OPS)  for  Masscomp  hosted  MCC  (TR-93-00305SB). 

d.  Version  Description  Document  (VDDl  for  Masscomp  hosted  MCC  rrR-93-003042V 

e.  Software  Design  Document  for  Masscomp  hosted  MCC  (Volumes  1  and  2,  June 
1991). 


3.11.3  Software. 

a.  BDS-D  MCC/Masscomp  Host  l.O.O  Source  and  Runtime  Files. 

b.  Masscomp  Real  Time  UNIX  (RTU)  Version  4.0A. 

3.11.4  Computer  Software  ConHguration  Item  (CSCI)  Breakdown. 

a.  Mother  Process  CSC. 

b.  see  Process  CSC. 

c.  Place  Process  CSC. 

d.  Admin.  Process  CSC. 

e.  Maint.  Process  CSC. 

f.  FSE  Process  CSC. 

g.  CAS  Process  CSC. 

h.  CEW  Process  CSC. 

i.  Terminal  Process  CSC. 

j.  Masscomp  Communications  Software  CSC. 

k.  Bridge  Process  CSC. 

l.  Appletalk  Software  CSC. 

m.  see  Console  CSC. 

n.  Place  Console  CSC. 

o.  Admin.  Console  CSC. 

p.  Maint.  Console  CSC. 

q.  FSE  Console  CSC. 

r.  CAS  Console  CSC. 

s.  CEW  Console  CSC. 

t.  Network  Communications  Libraries  CSC. 

u.  MCC  Libraries  CSC. 

V.  Macintosh  Libraries  CSC. 
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3.12  MIPS  Hosted  Management  Command  and  Control  (MCC). 

3.12.1  Description. 

The  MCC  System  (Figure  3.12.1-1)  is  used  in  setting  up  simulations  and  simulating  elements 
of  the  battlefield  environment.  It  tracks  the  condition  of  the  various  manned  simulators  for 
which  it  is  responsible,  as  well  as  vehicles  that  it  generates  for  service  and  repair.  TIk  MCC 
also  handles  various  aspects  of  mine  laying  and  monitors  the  availability  of  fuel  and 
ammunition.  The  MIPS  computer  has  greater  computational  power  than  the  original  MCC 
Masscomp  host.  It  maximizes  the  use  of  the  existing  SAF  code  and  allows  the  MCC  vehicles 
to  be  both  visible  and  vulnerable  at  all  times. 


SIMNET  NETWORK 


Figure  3. 1 2. 1  - 1 .  MIPS  Hosted  Management  Command  and  Control  (MCC)  Diagram 

3.12.2  Documentation. 

a.  Software  Maintenance  Manual  (SMMl  for  the  MIPS  MCC  rrR-93-Q03063AV 

b.  Operations  Manual  (OPS)  for  the  MIPS  MCC  (TR-93-003055B1. 

c.  Version  Description  Document  (VDDl  for  the  MIPS  MCC  rrR-92-0Q3037’). 

3.12.3  Software. 

a.  MacPlus  OS  Release  6.0.3. 

b.  MIPS  RISC  OS  4.5.1. 

c.  CAP  6.0  KIP  (Kinetics  IP  Appletalk  Daemon). 
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d.  SIMNET  Device  Driver 

e.  Shiva  FastPath  Version  4.0  (or  higher). 

3.12.4  Computer  Software  Configuration  Item  (CSCI)  Breakdown. 

a.  Mother  Process  Computer  Software  Component  (CSC). 

b.  see  Process  CSC. 

c.  Place  Process  CSC. 

d.  Terminal  Process  CSC. 

e.  MIPS  Communications  Software  CSC. 

f.  Appletalk  Software  CSC. 

g.  see  Console  CSC. 

h.  Network  Communications  Libraries  CSC. 

i.  MCC  Libraries  CSC. 

j.  Macintosh  Libraries  CSC. 

3.13  Network  Protocols. 

The  BDS-D  network  is  in  the  process  of  migrating  from  SIMNET  protocols  to  DIS  protocols. 
Currently  all  BDS-D  sites  support  SIMNET  only.  The  SIMNET  protocols  are  described  in  the 
SIMNET  Network  and  Protocols 

The  next  generation  of  Distributed  Interactive  Simulation  (DIS)  protocols  is  being  developed  by 
the  Workshops  on  the  Interoperability  of  Defense  Simulations.  Workshops  are  held  biennially 
and  have  lead  to  the  formal  adoption  in  March  1993  of  the  Standard  for  Information 
Technology  -  Protocols  for  Distributed  Interactive  Simulation  Applications  [IEEE,  1993]  as 
an  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  standard.  Development  of  the 
standard  has  continued;  and  the  latest  description  of  the  DIS  protocols  can  be  found  in  the  third 
draft  of  DIS  2.0,  which  was  released  in  May  of  1993*^. 

The  SIMNET  baseline  system  is  implemented  using  a  family  of  related  protocols.  These 
protocols  include  a  simulation  protocol,  a  data  collection  protocol,  and  an  association  protocol. 
The  simulation  protocol  is  used  to  introduce  simulated  elements  into  an  exercise,  remove  them 
from  an  exercise,  and  convey  information  about  the  simulated  world  for  use  by  simulators. 

The  data  collection  protocol  is  used  to  record  information  about  an  exercise.  The  association 
protocol  provides  communications  services  required  for  distributed  simulation  and  supports 
both  the  simulation  and  data  collection  protocols. 
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There  are  19  SIMNET  Simulation  Protocol  PDUs: 

a.  Activate  Request. 

b.  Activate  Response. 

c.  Deactivate  Request. 

d.  Deactivate  Response. 

e.  Vehicle  Appearance. 

f.  Radiate. 

g.  Fire. 

h.  Impact. 

i.  Indirect  Fire. 

j.  Collision. 

k.  Service  Request 

l.  Resupply  Offer. 

m.  Resupply  Received. 

n.  Resupply  Cancel. 

o.  Repair  Request. 

p.  Repair  Response. 

q.  Marker. 

r.  Breached  Lane. 

s.  MineField. 

There  are  four  kinds  of  SIMNET  Association  PDUs: 

a.  datagram. 

b.  request 

c.  response. 

d.  padding. 

t 

There  are  eight  SIMNET  Data  Collection  PDUs: 

a.  Exercise  Status. 

b.  Simulation  Status. 

c.  Vehicle  Status. 

d.  Status  Query. 

e.  Status  Response. 

f .  Status  Change. 

g.  Laser  Range. 

h.  Event  Flag. 
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The  network  requirements  for  running  SIMNET  protocol  are  summarized  below; 

a.  The  network  must  support  connectionless  data  transfer  (i.e.,  datagram  service). 

b.  A  datagram  must  be  able  to  convey  at  least  256  octets  of  information. 

c.  The  network  must  provide  for  either  broadcasting  of  datagrams  or  multicasting. 

d .  The  network  should  have  a  low  rate  of  non-delivery. 

e.  The  network  should  maintain  datagram  integrity. 

In  addition,  there  are  certain  performance  parameters  which  must  be  met  with  respect  to 
throughput  and  delay. 

4  ADST  SYSTEM  ENGINEERING. 

This  section  describes  the  mechanisms,  tools  and  facilities  employed  by  the  ADST  Program 
staff  to  provide  for  tracking  of  the  BDS-D  System  Definition  status.  Both  cun^nt  and  future 
capabilities  are  included,  as  appropriate,  to  afford  the  reader  a  better  understanding  of  the  data 
presented  in  this  document. 

A  major  focus  of  the  systems  engineering  effort  is  to  monitor  the  wide  variety  of  efforts  under 
ADST  cognizance  for  an  orderly  and  rapid  progression  towards  satisfying  the  BDS-D  Program 
Plan  exit  criteria.  In  particular,  the  systems  engineering  function  examines  projects  for 
deficiencies  and  inconsistencies  with  respect  to  fundamental  guiding  principles  (such  as  the 
DIS  architecture),  as  well  as  attempts  to  minimize  redundancies  between  D.O.s.  In  this  way, 
there  is  assurance  that  every  D.O.  can  capitalize  on  the  advances  made  by  other  D.O.s.  Figure 
4-1  illustrates  this  systems  engineering  process  and  its  relation  to  other  activities. 
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Figure  4-1.  System  Engineering  Diagram 

4 . 1  Configuration  Management. 

Configuration  Management  (CM)  is  a  set  of  processes  which  creates  and  maintains  a  high 
integrity  database  of  the  technical  details  of  a  system  and  establishes  a  set  of  procedures  for  the 
purpose  of  controlling  modifications  to  that  system.  The  CM  of  the  BDS-D/DIS  system  has 
multiple  dimensions,  chief  among  which  are  hardware  CM,  software  CM,  virtual  battlefield 
CM,  and  operational  procedures  CM.  These  dimensions  cover  all  manual  and  automated 
procedures,  machines,  and  information  elements  under  the  cognizance  of  the  ADST  program. 

4.1.1  Configuration  Management  Plan. 

A  Configuration  Management  Plan^^  ^as  been  developed  which  describes  the  organizations, 
baseline  identification,  configuration  controls,  interface  management,  traceability,  status 
accounting,  references  company  directives  where  appropriate,  and  configuration  management 
audits.  These  audits  are  provided  by  the  quality  assurance  organization,  which  writes  a  report 
once  it  has  performed  an  audit. 
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4.1.2  Hardware  Conflguration  Management. 

Hardware  CM  is  the  management  of  all  system  hardware  components,  to  include  power 
distribution  and  site  layout;  subsystem  electrical  signal  and  power  configuration;  rack 
elevations;  schematics;  and  hardware  inventories.  Currently,  hardware  CM  is  a  local  (site) 
responsibility.  Current  hardware  inventories  of  ADST  sites  are  available  upon  approved 
request  from  each  site. 

4.1.3  Software  Configuration  Management. 

Software  CM  is  regarded  as  a  major  subset  of  the  overall  Loral  and  ADST  configuration 
management  system.  An  established  SCM  team  provides  effective  management,  control, 
identification,  audit  and  status  accounting  over  the  evolving  ADST  BDS-D/DIS  configuration 
baselines  of  all  software  products,  and  their  technical  requirements,  and  conformance  to  these 
requirements.  The  software  configuration  consists  of  all  documents  produced  during  the 
software  engineering  defmitions  and  development  phases  (i.e.,  executable  code,  source  files, 
tests/results.  Cold  Start  Procedures,  and  Version  Description  Documents).  The  software 
configuration  is  controlled  in  a  concise  process  for  each  succeeding  software  engmeering  step. 

4. 1.3.1  Software  Baseline  Identification. 

The  ADST  team  approach  to  managing  the  software  life  cycle  is  based  on  establishing  a 
product  baseline.  The  Product  Baseline  (initially  SIMNET  Version  6.6.1)  is  used  as  the 
starting  baseline  for  subsequent  design  development  and/or  D.O.s.  Changes  to  the  product 
baseline  will  be  established  to  defme  a  formal  departure  point  for  control  of  future  revisions,  or 
deliveries.  In  the  event  that  a  new  simulator  is  developed,  configuration  identification  will  be 
established  in  the  form  of  technical  specifications  for  the  system,  the  system  segments,  and 
each  Configuration  nems  (CI/CSCI).  Hence,  Functional  ConBguration  Identification  (FCI) 
will  be  established  against  performance-oriented  requirements  for  the  segment  design  and 
performance. 

The  ADST  project  involves  the  development  and  maintenance  of  many  complex  software 
components  which  execute  on  several  hardware  platforms.  The  project  software  development 
is  not  for  the  purpose  of  achieving  one  delivery;  rather,  it  is  for  the  purpose  of  achieving 
multiple  releases  with  potential  increasing  capabilities  for  a  particular  conftguration. 


75 


ADST/WDLnrR  -94-03017  V3.0 
1994 


ADST  System  Definition  Document 


10  March 


The  elements  below  comprise  the  engineering  groundwork  required  to  support  a  D.O. 
Software  release  process.  The  elements  required  for  a  D.O.  package  may  vary  based  on 
requested  sponsorship  and  will  be  funded  with  each  D.O.  The  release  kit,  including  the  code, 
is  for  general  release  unless  specified  by  the  customer. 

a.  Delivery  of  a  Version  Description  Document  (VDD) 

b.  Provide  required  executable  code,  object  code,  data  files,  tables  and  parameter  files  to 
bring  up  a  system.  Include  a  read.me  file  with  appropriate  header  information  to 
identify  tapes  for  loading  software. 

c.  Cold  Start  Procedures  (CSP). 

d.  Installation  procedures. 

e .  Build  and  distribution  instructions. 

f .  Identification  ot  known  problems. 

g.  Regression  test  results. 

h.  English  narrative  synopsis  of  functionality  of  the  released  system. 

i .  List  of  documents  applicable  to  the  configuration. 

j.  Release  Notes,  if  appropriate,  depicting  notes/differences/compatibility  since  the  last 
release. 

k.  Provide  tools  to  support  any  necessary  on-site  regression  testing. 

l.  Provide  POC  (nama^phcne  number)  for  each  release. 

m.  User  Guides  (as  funded  by  a  D.O.). 

The  current  status  of  the  SWCCP  is  summarized  in  Table  4.1 .3.1-1 . 
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Table  4. 1 .3. 1  - 1 .  SWCCP  Current  Status 


sweep 

Xref 

Product  Title 

Asgd 

Current 

Baseline 

esp 

4 

Configuration  Management 
Plan 

LADS-SJ 

N/A 

N/A 

N/A 

Completed  / 
Accepted 

Common  Software  Study 

LADS-CB 

N/A 

N/A 

N/A 

Completed  / 
Accepted 

Software  Maintenance 

Manual 

TBD 

N/A 

N/A 

N/A 

On  hold 

5 

Software  Development  Plan 

LADS-SJ 

N/A 

N/A 

N/A 

To  be  worked  in 
Aueust 

6 

Ml/GT  Host  SW  Baseline 

LADS-SJ 

1.1.0  /  1-20- 
93 

1.0.0/  12-22- 
92 

Due 

7-21-93 

Completed  / 
Accepted 

6 

M  1/Masscomp  Host  SW 
Baseline 

LADS-SJ 

1.0.0  /  4-20-93 

4-20-93 

Completed  / 
Accepted 

7 

M2  Butterfly  Host  SW 

Baseline 

LADS-CB 

Need  Status 

Need  Status 

Need 

Status 

Awaiting  Status 

8 

NO&M  SW  Baseline 

LADS-CB 

Need  Status 

Need  Status 

Need 

Status 

Awaiting  Status 

9 

RWA  SW  Baseline 

LADS-SJ 

1.4.4  /  3-17- 
93 

1.0.0  /  11-22- 
92 

5-21  93 

* 

Completed  /  ♦ 
Await  Accept 

10 

Stealth  Masscomp  Host  SW 
Baseline 

LADS-OR 

TBD 

TBD 

TBD 

Transfer  Oilando 

10 

Stealth  GT  Host  SW  Baseline 

LADS-CB 

Need  Status 

Need  Status 

Need 

Status 

Awaiting  Status 

1 1 

SAP  (Symb/MIPS)  SW 
Baseline 

LADS-SJ 

TBD 

TBD 

TBD 

On  Hold. 

Skalnottv  Equip. 

12 

Dismounted  Infantry  SW 
Baseline 

lADS-OR 

TBD 

TBD 

TBD 

Transfer  Orlando 

13 

FWA  SW  Baseline 

LADS-OR 

TBD 

TBD 

TBD 

Transfer  Orlando 

14 

Data  Logger  SW  Baseline 

LADS-SJ 

2.0.0/  6-11- 
93 

1.0.0  /  4-9-93 

5-21-93 

* 

Completed  /  * 
Await  Accept 

16 

CVCOIVIS  SW  Baseline 

LADS-SJ 

TBD 

TBD 

TBD 

On  Hold 

17 

AirNet  MCOMIPS  Host  SW 
Baseline 

LADS-SJ 

2.0.0/  3-10- 
93 

1.0.0  /  12-22- 
92 

Partially 

Complete 

AirNet  MCOMac  Host  SCC 
SW  Baseline 

L/VDS-SJ 

1.0.0  /  3-23- 
93 

1.0.0/  WIP 

Due 

7-23-93 

Partially 

Complete 

18 

MCC/Masscomp  Host  SW 
Baseline 

LADS-SJ 

2.0.0  /  3-24- 
93 

1.0.0  /  4-19-93 

* 

5-21-93 

Completed  /  * 
Await  Accept 

MCC/Mac  Host  Admin  SW 
Baseline 

LADS-SJ 

2.0.0/  5-11- 
93 

2.0.0  /  WIP 

WIP 

Partially 

Complete 

MCC/Mac  Host  CAS  SW 
Baseline 

L/U)S-SJ 

1.1.0  /  2-10- 
93 

1.1.0/  WIP 

WIP 

Partially 

Complete 

MCC/Mac  Host  CEC  SW 
Baseline 

LADS-SJ 

1.1.0  /  2-10- 
93 

1.1.0/  WIP 

WIP 

Partially 

Complete 

MCOMac  Host  FSE  SW 
Baseline 

LADS-SJ 

1.1.0  /  2-10- 
93 

1.1.0/  WIP 

WEP 

Partially 

Complete 

MCOMac  Host  Maint  SW 
Baseline 

LADS-SJ 

2.0.0  /  5-11- 
93 

2.0.0  /  WIP 

WIP 

Partially 

Complete 

MCOMac  Host  Place  SW 
Baseline 

LADS-SJ 

1.1.0  /  2-10- 
93 

1.1.0/  WIP 

WIP 

Partially 

Complete 

MCOMac  Host  SCC  SW 
Baseline 

LADS-SJ 

2.0.0  /  WIP 

WEP 

Partially 

Complete 

PVD  SW  Baseline 

LADS-SJ 

1.1.0  /  4-7-93 

1.0.0  /  4-9-93 

5-21-93 

« 

Completed  /  * 
Await  Accept 
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Table  4. 1 .3. 1  - 1 .  SWCCP  Current  Status  (Continued) 


1  Non- 

sweep 

Products 

Under 

eM 

eontrol 
or  In 
Work 

Product  Title 

Asjtd 

Current 

Baseline 

VDD 

esp 

Notes 

CSRDF/Protocol  Trans  SW 
Baseline 

LADS-SJ 

1.3.3  /  5-28- 
93 

1.0.0  /  4-28-93 

* 

4-28-93 

* 

Completed  /  * 

Await  Accept 

ATAC II  SW  Baseline 

LADS-SJ 

1.1.0  /  4-7-93 

1.1.0 /Due  8-6- 
93 

Due  8-6- 
93 

Working 

Documentation 

Ml  CIG  SW  Baseline 

N/A 

N/A 

N/A 

N/A 

Not  to  be  worked 

Ml/XROD  SW  Baseline 

LADS-SJ 

1.1.0  /  11-2- 
92 

1.1.0  /  12-22- 
92 

Due7- 

21-93 

Partially 

Complete 

VIDS-Ml  SW  Baseline 

LADS-SJ 

1.0.0  /  6-4-93 

After  Phase  II 

Phase  II 

Builds  Completed 

VIDS-CCDP  (PC  Code)  SW 
Baseline 

LADS-SJ 

1.0.0  /  6-4-93 

After  Phase  II 

Phase  11 

Builds  Completed 

VIDS-MCC  SW  Baseline 

LADS-SJ 

1.0.0  /  3-24- 
93 

After  Phase  11 

Phase  II 

Builds  Completed 

VIDS-Mac  see  SW  Baseline 

LADS-SJ 

1.0.0  /  3-22- 
93 

After  Phase  U 

Phase  11 

Builds  Completed 

VIDS-SAFOR  SW  Baseline 

After  Phase  11 

Phase  11 

VIDS-  SMS  SW  Baseline 

LADS-SJ  1 

WIP 

N/A 

N/A 

WIP 

NLOS  SW  Baseline 

N/A 

N/A 

N/A 

Await  release  to 

CM  9-93 

4. 1.3.2  Software  Change  Control. 

The  control  process  for  each  product  or  D.O.  under  development  adheres  to  a  set  of  activities 
that  is  accomplished  in  a  particular  order  to  conform  to  the  building  block  approach  of  the 
Software  Problem/Change  Report  (SP/CR)  validation  and  verification.  The  CM  tools  and 
directory  structure  provide  CM  with  the  ability  to  uniquely  identify  and  build  a  D.O.  product 
baseline.  In  this  process,  there  are  related  phases  that  provide  the  ability  to  incrementally  build 
on  a  foundation  of  a  tested,  controlled,  and  validated  baseline.  There  is  one  CM  library  area 
that  is  managed  and  maintained  by  the  CM  team.  This  domain  is  referred  to  as  the  Software 
Support  Library  (SSL).  An  identical  structure  is  created  from  the  CM  area  for  developers  to 
perform  upgrades.  Here,  developers  code  and  build  their  changes.  After  successful 
development  /  unit  test  on  the  target  machine,  the  change  is  turned  over  to  CM  for  control  and 
incorporation  into  the  CM  baseline  via  an  approved  SP/CR.  Figure  4.1. 3.2-1  provides  a 
graphical  view  of  the  CM  SSL  structure. 
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Figure  4. 1 .3.2- 1 .  Software  Support  Library  Structure 

The  CM/SSL  baseline  structure  is  a  controlled  envirorunent,  which  provides  protection  from 
unauthorized  software  changes.  It  contains  modules  which  have  been  identified  by  software 
engineers  for  control  and  are  managed  by  the  Configuration  Management  team  under  the 
Revision  Control  System  (RCS)  or  other  CM  software  packages  as  applicable.  These  modules 
have  been  built  (compiled  and  linked)  to  produce  an  application  build  load  or  D.O.  Each  build 
load  is  flagged  via  RCS  with  a  revision  number  associated  with  the  particular  D.O.  Changes  to 
software  modules  will  be  identified  by  an  SP/CR  number  in  the  header  /  prologue  block  of  the 
source.  The  SP/CR  will  remain  open  until  the  change  has  been  validated  through  regression 
testing  in  a  closely  monitored  integration  environment. 

The  development,  test,  and  operational  software  baselines  are  maintained  in  directory  structures 
on  the  target  machines  under  the  SSL  that  are  closely  monitored  by  CM.  The  CM  Baseline 
directories  contain  a  snapshot  of  the  controlled  baselines,  which  can  be  used  to  recreate  a  given 
environment.  The  Operational  Baseline  directory  contains  software  which  has  been  derived 
from  some  baseline,  upgraded,  tested,  controlled,  and  labeled  “operational.”  This  directory 
and  all  subdirectories  are  under  CM  control  by  use  of  operating  system  protections.  The  Test 
Baseline  directory  contains  a  CM-built  baseline  which  is  not  yet  operational.  Formal  testing  of 
software  “captured”  from  developers  is  performed  in  this  area.  Wlwn  this  testing  process  has 
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determined  that  the  software  is  working  properly,  it  is  moved  into  the  Operational  baseline 
directory  by  CM. 

The  Development  Baseline  area  is  where  build  loads  are  downloaded  and  distributed  to  the 
designated  development  configurations  in  the  Software  Development  Facility  (SDF)  for  SP/CR 
incorporation  and  further  development  and  unit  testing. 

A  CM  library  hierarchy  has  been  established  and  includes  separate  RCS  libraries  for  the 
specific  baselines.  Included  in  each  baseline  are  source  code,  test  plans,  and  documentation. 
This  library  hierarchy  mirrors  each  vehicle  and  simulation  subsystem  development  directory 
structure,  thus  facilitating  the  transfer  of  data  while  maintaining  consistency  of  identification 
and  design.  Figure  4. 1 .3.2-2  provides  a  sample  of  the  high  level  overview  of  the  BDS-D  SSL 
directory  structure.  Detailed  module  trees  for  each  configuration  can  be  obtained  ftom  the  CM 
organization.  In  addition,  each  configuration  Version  Description  Document  contains  a  listing 
of  the  files  and  hierarchy  structure. 
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Figure  4. 1 .3.2-2.  CM  SSL  Baseline  Hierarchy 


4. 1.3.2. 1  Software  Configuration  Controi  Process. 

The  primary  reporting  mechanism  for  changes  to  the  BDS-D/D.O.  system  configurations  is  via 
the  Software  Problem/Change  Report.  The  SP/CR  is  used  by  the  sites  and  the  Configuration 
Control  Board  (CCB)  to  resolve  design  and  document  issues  to  the  CM  controlled  software 
baseline.  The  SP/CR  provides  the  means  for  reporting  errors  in  development,  test,  and 
operational  software  and/or  hardware.  An  SP/CR  is  completed  by  any  user  or  developer  who 
discovers  a  system  anomaly,  or  desires  a  modification  in  order  to  improve  system  operational 
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efficiency.  The  SP/CR  provides  a  formal  means  for  recording  all  software  and  hardware 
faults  and  modification  requests.  Each  SP/CR  will  be  submitted  to  the  CCB  or  respective  site 
representative/D.O.  Manager  for  analysis.  SP/CRs  which  are  out  of  scope,  such  as  beyond  the 
normal  schedule,  scope  of  current  activities,  budget  or  enhancements/improvements,  will  be 
forwarded  to  the  LORAL  WDL  Program  office  for  resolution.  An  SP/CR  status  report,  which 
serves  as  the  agenda,  is  prepared  and  distributed  by  Configuration  Management  in  a  timely 
manner  to  support  the  functions  of  the  Board.  Since  the  CCB  representatives  may  be  located 
at  various  facilities,  technical  interfacing  will  be  accomplished  via  the  conference  phone.  Status 
on  all  of  the  above  actions  from  the  CCB  will  be  provided  to  the  ADST  Program  Office  and  the 
Delivery  Order  Managers. 

4. 1.3. 2. 2  Operating  Procedures. 

Maintenance  of  such  a  large  baseline  is  particularly  challenging  when  multiple  sites,  hardware 
configurations,  software  configurations,  and  development  organizations  are  involved.  This  is 
further  compounded  by  the  fact  that  these  sites  are  geographically  scattered  across  the  country. 
As  a  result,  it  is  important  to  define  the  procedures  by  which  the  existing  baseline,  SIMNET 
Version  6.6.1,  is  distributed  to  the  various  users  for  installation  on  simulators,  development 
efforts  on  delivery  orders,  and  for  use  on  other  efforts  not  necessarily  related  to  ADST.  A 
series  of  software  support  operating  procedures  (SSOP)  have  been  written  that  describe  how 
various  activities  related  to  the  baseline  will  be  performed.  These  procedures  are: 

a.  SSOP  1  -  SSOP  Purpose/Procedure. 

b.  SSOP  2  -  Configuration  Control  Board  (CCB)  Charter. 

c .  SSOP  3  -  Problem  Reporting  Procedure. 

d .  SSOP  4  -  Integration  and  Test  Procedure. 

e .  SSOP  5  -  Code  Checkout/FTP  Procedure. 

f.  SSOP  6  -  ADST  SDF  Lab  Rules  and  Procedures. 

g .  SSOP  7  -  Configuration  Management  Turnover  Procedure. 

h .  SSOP  8  -  RCS  Header  Comment  Standards. 

i .  SSOP  9  -  Delivery  Order  Release  Kit  Procedure. 

j.  SSOP  10  -  CM/SDF  Build  Load  Distribution  Procedure. 

k .  SSOP  1 1  -  ADST  SDF  Lab  Rules  and  Procedures. 

l.  SSOP  12  -  Revision  Control  System  (RCS)  Procedure, 

m.  SSOP  13  -  Change  Control/Build  Procedure  Field  Support. 

n .  SSOP  1 4  -  SP/CR  Audit  Trails. 
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o.  SSOP  15  -  BDS-D  Data  Transfer. 

p.  SSOP  16  -  ADST  Documentation  Preparation. 

4.1.4  Virtual  Battlefield  CM. 

The  CM  of  the  virtual  battlefield  is  the  systematic  tracking  of  the  ctmfiguration  of  the  objects 
which  appear  on  the  BDS-D  virtual  battlefield.  To  effect  this  CM,  a  process  closely  related  to 
VV&A  (see  section  4.2.3)  must  take  place,  i.e.,  the  establishment  of  a  detailed  database  which 
contains  the  information  necessary  to  describe,  build,  and  validate  battlefield  objects  on  the 
simulation.  Progress  toward  development  of  such  a  capability  has  been  made  in  both  the 
VV&A  subtask  and  the  database  subtasks  of  the  BD-D  Architecture  Study,  in  particular  with 
the  evolution  of  the  database  concept.  Current  virtual  battlefield  weapon  systems  and  objects 
are  described  briefly  in  Section  4.2.2  of  this  document. 

4.1.5  Configuration  Control  Board  (CB). 

The  Loral  San  Jose  DL  Configuration  Control  Board  (CB)  is  designated  as  the  Central  CB  (i.e. 
single  control  point)  for  all  changes  to  the  established  BDS-D  software  product  baselines.  In 
order  to  ensure  consistency  between  the  site  development  changes  and  the  central  software 
baseline,  all  CM-related  operations  require  communication  and  coordinaticm  in  cooperation 
between  the  San  Jose  CM  staff,  D.O.  Managers,  and  site  representatives.  The  sites  will 
apprise  the  CB  of  any  possible  or  proposed  changes  to  the  product  baseline.  The  respective 
D.O.  Manager  and  site  representative  will  review  and  approve  site-generated  PS/Cs. 
Configuration  reviews  and  the  CB  will  ensure  proper  application  of  configuration  control  and 
establish  the  basis  for  status  accounting.  The  CB  will  provide  active  program  support  and 
establish  a  team  for  coordinating,  monitoring,  and  implementing  change  control.  The  CB  will 
interact  with  the  Loral  Ireland  Program  Management  Office,  site  representatives,  and  with  the 
customer  to  adjudicate  proposed  changes  to  the  baselines. 

4.1.6  Configuration  Tracking. 

The  CM  organization  is  responsible  for  tracking  the  various  versions  of  hardware  and  software 
comprising  the  SIGNET  community.  For  instance,  the  Management  Control  Console  (CM) 
may  be  the  same  hardware  configuration  at  Fort  Knox  and  Fort  Rucker,  but  be  miming 
different  software  loads  as  a  result  of  changes  being  implemented  at  one  site  in  support  of  a 
delivery  order.  Not  only  will  the  CM  organization  track  these  changes,  they  will  also  be  able  to 
archive  and  retrieve  a  historical  software  release  should  the  need  arise.  The  process  becomes 
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even  more  complex  in  cases  where  CM  must  maintain  the  build  in  use  at  the  training  sites, 
support  multiple  ongoing  development  efforts  in  the  that  change  the  hardware  configuration, 
while  supporting  both  on  site  and  off  site  development. 

The  necessity  for  maintaining  tractability  to  the  parent  configuration,  both  from  a  hardware  and 
software  point  of  view,  requires  adherence  to  the  documented  procedures  described  in  the 
previous  section. 

Another  dimension  to  the  configuration  tracking  process  is  the  requirement  to  identify  the 
development  system  required  to  support  the  target  system,  as  they  are  often  different  hardware 
suites.  Not  only  must  the  development  system  configuration  be  identified,  its  location  must 
also  be  tracked  since  development  can  take  place  at  many  different  locations. 

4.1.7  Configuration  Status  Accounting. 

Configuration  Status  Accounting  will  be  the  means  through  which  control  and  tracking  of 
discrepancies  and  change  requests  affecting  Cl/CSCIs  are  reported  to  STRICOM  and 
engineering  managers  concerned. 

The  Configuration  Status  Accounting  contains  a  Configuration  Identification  List,  D.O.  Status 
Log,  and  Version  Descriptions  Documents.  Whenever  a  status  change  occurs,  the 
Configuration  Identifications  Database  is  updated  to  reflect  its  current  status.  Approved  D.O.s 
to  the  product  baseline  developmental  configurations  are  listed,  thus  providing  a  status 
accounting  of  D.O.s  against  each  CSCI. 

4.1.8  Configuration  Audits. 

Formal  configuration  audits  and  reviews  for  the  ADST  program  are  not  a  requirement  of  the 
sweep.  However,  informal  technical  reviews  and  technical  audits  will  be  part  of  the 
surveillance  throughout  the  life  cycle  of  the  project. 

In  addition,  a  Software  Quality  Assurance  (SQA)  function  is  in  place  and  is  responsible  for 
monitoring  internal  configuration  management  procedures  that  ensure  compliance  with  the 
sweep  and  CMP.  The  SQA  representative  provides  a  continuing  check  on  all  software 
maintained  for  the  ADST  program.  SQA  coordinates  and  periodically  audits  the  configuration 
maintenance  activities  to  ensure  consistency  between  the  controlled  documentation,  software, 
and  database  elements  comprising  each  D.O.  configuration  SQA  works  with  CM  to  ensure 
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that  baseline,  status  accounting,  library  and  change  control  procedures  are  being  q)piopriately 
presented  to  the  CCB.  SQA  will  conduct  a  review  of  all  products  in  conjunction  with  a  major 
software  baseline  capture  and/or  release,  in  lieu  of  a  PCA/FCA. 


4.2  Topics  and  Activities. 

4.2.1  System  Architecture  Definition. 

A  key  function  of  the  ADST  systems  engineering  staff  is  the  definition  of  an  open  architecture 
to  support  the  BDS-D  exit  criteria.  Such  an  architecture  was  first  introduced  in  the  Strawman 
Architecture  document  and  has  continued  to  develop  in  the  subsequent  periods  of 
performance  of  the  ADST  contract.  The  latest  architectural  information  is  contained  in  the 
following  series  of  documents. 


a.  System  Design  Specification  for  the  Battlefield  Distributed  Simulation  -  Developmental 
(BDS-D)  System  Version  1 .0.^Q  This  document  defines  the  requirements  for  the 
various  components  that  are  to  be  developed  for  integration  within  the  standards  and 
guidelines  established  for  Distributed  Interactive  Simulation  (DIS)  as  applied  to  BDS-D 
Version  1 .0.  This  document  contains  discussion  of  all  major  BDS-D  architectural 
components  (Table  4.2. l-l). 
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Table  4.2. 1  - 1 .  BDS-D  Architectural  Components 


DIS  Basic  Interface  Package  (BIP) 

DIS  Test  Tools 

DIS  Cell  Interface  Unit  (CIU) 

DIS  Cell  Adapter  Unit  (CAU)  for  Virtual  Cell 

BDS-D  Simworld  Database 

DIS  Extensions  Interface  Package 

DIS  Session  Manager 

DIS  MCC 

DIS  After  Action  Review  (AAR)  Station 

DIS  Plan  View  Display 

1  DIS  Visual  Stealth 

I  DIS  Radio  Stealth 

1  DIS  Data  Logger 

1  DIS  Statistical  Analysis  Package 

1  DIS  Environmental  Simulator 

1  DIS  Long  Haul  Network 

1  DIS  Security  Unit 

1  DIS  Network  Manager 

1  DIS  ModSAF  Upgrade  ~ 

1  DIS  CAU  for  Constructive  Cell 

IdIS  CAU  for  Live  Cell 

b.  Distributed  Interactive  Simulation  (DlS)  Architecture  Description  E)ocument.^^  This 
document  is  an  update  of  the  original  Strawman  Architecture  document. 

c.  System  Design  ICD  for  the  BDS-D  System  Version  1.0.^^  This  document  is  an 
interface  requirements  specification  (IRS)  and  examines  all  external  system  interfaces 
that  allow  other  simulation  systems  to  interact  with  the  components  of  the  BDS-D 
Version  1.0  System. 

d.  BDS-D  System  Deyelopment  Plan.  Rey  1.0.^3  This  document  proyides  guidance  and 
focus  for  ADST  activities  as  they  relate  to  the  BDS-D  System.  It  defines  the  specific 
simulation  assets,  including  sites  and  simulator  devices,  that  will  be  included  in  the 
BDS-D  Version  1.0  system  and  outlines  a  phased  development  plan. 

e.  PIS  Common  Database  Standard.^^  This  document  establishes  the  requirements  for 
the  CDB  for  the  DIS  system.  The  purpose  of  the  DIS  CDB  is  to  provide  a  standard 
means  of  structuring,  configuring,  populating,  and  maintaining  databases  for  DIS 
exercises  and  experiments. 
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4.2.2  The  Synthetic  Environment  and  the  Common  Database. 

System  engineering  also  addresses  the  synthetic  environment  (virtual  battlefield).  The 
synthetic  environment  can  be  described  in  terms  of  the  simulation  entities  and  the  simulated 
environments  in  which  they  interact.  Description  of  the  simulators,  SAPOR,  and  other 
devices  (assets)  used  to  produce  the  simulation  is  by  itself  inadequate  to  provide  an 
understanding  of  what  the  synthetic  environment  itself  is  like.  A  further  step  in  this  process  is 
to  identify  and  describe  the  systems  replicated.  For  example,  currently  modeled  weapon 
systems  at  the  MWTB  and  AVTB  are  summarized  in  Table  4.2.2- 1 . 


Table  4.2.2- 1.  Currently  Modeled  Weapon  Systems 


SYSTEM 

us  MODELS 

OPFOR  MODELS 

Tank 

MlAl,MlAi 

T75 

Armd  Pers  Carrier 

M2  Bradley 

BMP2 

Artillery 

M109(155MM^ 

2S3(152MM) 

Air  Defense 

ADATS 

ZSlJ23-4 

Mortars 

Ml  06  (4.2inch) 

Rotary  Wing 

Apache,  OH-58  Scout 

Hind,  Havoc  || 

SU-25  Frogfoot  1 

il  Engineer 

M113,M57,M58,M128 

M5S 

- 

1  Fuel,  Ammo  Trucks 

HEMMrt 

- 

II  Tactical  Ops  Center 

M577 

- 

Markers,  Breech  Lane 

- 

" 

The  synthetic  environment,  however,  is  much  more  complex  than  a  list  of  simulation  entities. 
Each  of  these  simulation  entities  has  certain  capabilities  and  susceptibilities  which  interact  in 
meaningful  ways  with  other  simulation  entities  but  not  others.  One  of  the  activities  of  ADST 
system  engineering  is  to  discover  ways  of  describing  the  public  attributes  of  simulation  entities 
and  environments  so  that  they  may  be  configured  into  useful  exercises.  The  Common 
Database  (CDB)  is  the  major  architectural  component  responsible  for  this  task. 


The  CDB  is  organized  into  three  component  databases.  The  SIMWORLD  Database  (SWDB) 
contains  data  relating  to  the  description  of  the  simulation  entity  and  simulation  asset  types.  The 
SWDB  also  contains  information  about  SIMWORLD  characteristics  such  as  performance, 
validation,  and  interoperability  data.  The  Session  Database  (SDB)  instantiates  the  simulation 
entity  types  into  specific  simulation  entities  in  synthetic  environment  scenarios.  Similarly,  the 
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SDB  configures  simulation  assets  into  networks  of  assets  (devices).  The  Review  Database 
(RDB)  contains  data  relating  to  the  archiving  of  data  and  its  subsequent  analysis. 

The  CDB  is  intended  to  provide  a  flexible  and  extendible  means  of  making  explicit  the  various 
attributes  of  simulation  entities  (as  well  as  simulation  assets)  which  may  affect  the 
interoperability  of  the  simulation.  These  attributes  can  be  expressed  in  terms  familiar  to  the 
military  user,  and  are  compatible  with  those  found  in  standard  miliLo^y  references  such  as 
TRADOC  Pamphlet  1 1-9,  Blueprint  of  the  Battlefield. 

4.2.3  Simulation  Verification,  Validation,  and  Accreditation  (VV&A). 

Simulation  validation  has  been  addressed  through  the  BDS-D  Feasibility  Analysis  Study  Step  ' 
D.O.  This  effort  will  yield  a  Model  Verification,  Validation,  and  Accreditation  (VV&A)  plants 
which  is  directed  toward  ensuring  the  development  of  a  BDS-D  simulation  system  that  will  be 
used  to  produce  credible  results  for  its  various  users.  This  plan  could  form  the  basis  of  a 
VV&A  effort  for  a  suitable  Step  2  D.O.  Key  points  of  this  plan  include: 

a.  A  VV&A  characterization  database,  implemented  compatibly  with  the  BDS-D 
database  system,  and  containing  a  non-empty  intersection  with  the  SIMWORLD 
database. 

b.  Distinct  strategies  for  accrediting  existing  models  and  models  specifically  developed 
under  BDS-D. 

c.  Validation  and  partial  accreditation  for  specific  mission  areas  independent  of,  and  in 
advance  of,  knowledge  of  specific  experiments  hosted  on  the  BDS-D. 

4.2.4  Networked  Simulation  Standards. 

The  BDS-D  System  relies  on  IndusUy  to  develop  the  majority  of  the  required  simulation 
standards.  Since  appropriate  industrial  standards  are  not  always  available  when  needed,  or  do 
not  always  include  needed  capabilities  and  services,  BDS-D  relies  upon  specific  woricing 
groups  to  lead  the  effort  in  lobbying  and  guiding  Industry  toward  incorporating  the  needed 
standards.  The  following  (Table  4.2.4- 1)  is  a  list  of  the  working  groups  currently  tracked  by 
the  ADST  Program. 
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Table  4.2.4- 1.  Networked  Simulation  Standards  Activities 


mmmimsLmm 

Distributed  Interactive 
Simulation  (DIS) 

Simulation  Architecture 

Network  Protocols 

Simulation  Environment 

Communication  Architecture 

Simulation  Assessment 

stricOm 

(using  the  1ST) 

Defense  Modeling 
and  Simulation 
Initiative  Groups 

All  aspects  of  Modeling  and  Simulation 

Defense  Modeling  and 
Simulation  Office 
(DMSO) 

Joint  Modeling  and 

Simulation 

System(JMASS) 

Modeling  and  Simulation  Architecture 

DDR&E(T«&E) 

Project  285 1 

Terrain  database  standards 

Joint  Services 

Air  Force  Lead 

Multipeer  Multicast 
Consortium 

Multipeer/  Multicast  promotion  to 
International  Standards  Groups 

Consortium  Members 

ALSP 

Higher  Order  Model  Communication 

DARPA 
(using  MITRE) 

4.2.4. 1  Modular  Simulator  Standards. 

Current  plans  include  the  development  of  a  reconfigurable  rotary  wing  aircraft  simulator  based 
upon  the  MODular  SIMulator  (MODSIM)  standards  developed  under  Joint  Service 
sponsorship,  lead  by  the  Air  Force  (USAF  Project  2968)  using  the  Boeing  Company 
(Aerospace  and  Electronics  Division).  The  main  concept  important  to  BDS-D  is  the  modular 
architecture  which  groups  associated  aircraft  ftmctions  with  common  communication  interfaces 
such  that  they  may  be  re-used  in  future  aircraft  simulators  requiring  similar  functionality. 

The  JMASS  group  is  attempting  to  collect  and  catalog  simulation  models  with  the  intent  of 
establishing  a  model  source  available  to  future  developers  of  simulation  devices  and  systems. 
Future  editions  of  this  document  will  attempt  to  reference  available  JMASS  simulation  models 
and  data. 


4. 2. 4. 2  Network  Protocol  Standards. 

BDS-D  will  adhere  to  the  standards  developed  by  the  DIS  Working  Groups.  The  standard 
required  for  BDS-D  is  the  candidate  IEEE  Standard  for  Information  Technology  -  Distributed 
Simulation  Applications  -  Process  and  Data  Entity  Formats,  PI 278.  A  copy  of  the  latest 
standard  is  maintained  on-line  in  the  ADST  Bulletin  Board.  For  information  contact  the 
Institute  for  Simulation  and  Training,  12424  Research  Parkway,  Suite  300,  Orlando,  FL 
32826. 
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4.2.5  Terrain  and  Sensor  Databases. 

BDS-D  will  be  supported  by  the  Topographic  Engineering  Center  (TEC)  in  the  acquisition  or 
development  of  terrain  databases.  All  BDS-D  terrain  databases  will  adhere  to  the  Standard 
Interface  Format  (SIF)  developed  under  Project  2851.  Information  regarding  Project  2851 
activities  and  standards  may  be  obtained  by  contacting  COL  Richard  Tebay,  ASD/YWSA. 
SIMNET  terrain  databases  are  summarized  in  Table  4.2.5- 1 . 
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Table  4.2.5- 1 .  SIMNET  Terrain  Databases 


NAME 

SOURCE 

DEV, 

TOOL 

AREA 

COVERED 

AVTB 

MWTB 

VERSION 

Ft.  Knox 

3KManVView 

BBN 

SIOOO 

50km  Y  -  75km 

X 

■ 

■ 

knox3cow.001 

7  KM  Thermal 

EH 

EH 

knox7cdh.001 

7KMarWView 

EH 

EH 

knox7coh.001 

MCC 

EH 

EH 

KNOX.0311 

SAFOR  Mips 

EH 

EH 

KNOX.0311 

SAFOR  Symbolics  World 

IH 

EH 

Knox-Terrain  8.0 

Ft.  Hunter  Liggen 

3KMOTWView 

BBN 

SI  000 

50km  by  50km 

■ 

m 

hunt3cow.001 

7  KM  Thermal 

EH 

7KMarwView 

EH 

MCC 

EH 

HUNTER.Ol  10 

SAFOR  Mips 

EH 

EH 

HUNTER.Ol  10 

SAFOR  Symbolics  World 

EH 

EH 

Hunter-Liggett  6.0 

NTC 

3KMOTWView 

SIOOO 

50km  by  50km 

■ 

|H 

ntc3cow.00! 

7  KM  Thermal 

EH 

7KMOTWView 

EH 

MCC 

iH 

SAFOR  Mips 

iH 

SAFOR  Symbolics  World 

EH 

D  sub  saki 

3KMOTWView 

TEC 

SIOOO 

80km  Y  -  96km 

X 

■ 

■ 

dsub3cow.006 

7  KM  Thermal 

iH 

7KMOTWView 

EH 

MCC 

EH 

ds_sub_0102 

SAFOR  Mips 

EH 

Eh 

ds_sub_0102 

SAFOR  Symbolics  World 

EH 

Hi 

DS_Terrain  2.0 

Ft.  Hood 

3KMOTWView 

7  KM  Thermal 

7KMOTWView 

BBN 

SIOOO 

50  km  by  50  km 

■ 

1 

hood3cow.00c 

MCC 

Hood.0103 

SAFOR  Mips 

IH 

Hood.0103 

SAFOR  Symbolics  World 

m 

EH 

Hood  Terrain  2.0 

Bergen  Hochne 

3KMOTWView 

7  KM  Thermal 
7KMOTWView 

MCC 

SAFOR  Mips 

SAFOR  Symbolics  World 

SIOOO 

25km  by  25km 

berg3cow.00! 
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4.2.6  Tape  Backup  Library. 

A  tape  backup  libraiy  will  be  maintained  under  the  SSL  and  CM  control  for  all  software 
packages  used  on  the  development  and  target  machines. 

4.2.7  Technical  Reference  and  Training  Library. 

CM  will  maintain  a  libraiy  of  technical  manuals,  text  books,  video  cassettes,  and  vendor 
manuals  needed  to  support  the  software  development  program. 

4.2.8  Software  Reuse. 

The  SSL  supports  a  central  point  library  collection,  maintenance,  and  distribution  of  reusable 
software  parts.  Software  that  is  developed  as  a  result  of  other  build  configurations  may  be 
used  in  another  application  with  little  or  no  modification.  The  software  parts  are  made  up  of 
reusable  software  components  and  support  documentation  where  applicable.  An  example  of 
software  reuse  under  the  BDS-D  umbrella  is  the  GT  Ml  code.  This  code  has  been  applied  to 
the  M 1/XROD  delivery  order,  the  CVCC  delivery  order,  and  the  VIDS  delivery  order.  RWA 
is  another  example  of  code  used  on  other  delivery  orders  such  as  ATAC II  and  the  Commanche 
upgrade.  In  addition,  the  SSL  for  the  SIMNET  baseline  has  an  identified  conunon  libraiy 
where  databases,  data  files,  and  weapon  applications  are  pulled  into  various  configurations.  In 
addition,  reusable  software  includes  design  documentation  and  Cold  Start  Procedures.  All 
reusable  software  on  ADST  is  subject  to  the  same  maintenance  and  change  control  activities  as 
all  other  baselined  code. 

4.2.9  Software  Support. 

The  vehicles  for  software  support  are  largely  through  D.O.s  and  the  Software  Contract  Change 
Proposal  (CCP). 

4.3  Information  Services. 

This  section  discusses  the  capabilities  for  technical  information  access  and  exchange  provided 
for  under  the  ADST  contract.  A  major  portion  of  this  activity  will  be  migrating  the  SIMNET 
baseline  system  to  the  BDS-D  system.  With  this  move  towards  an  open-systems  architecture 
and  standardized  interfaces,  it  is  anticipated  that  larger  sectors  of  Government,  Industry,  and 
Academia  will  be  participating  in  the  design,  development,  production,  and  analysis  of 
activities  covered  under  the  AI>ST  program.  To  facilitate  synergy  among  these  diverse  and 
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distributed  groups,  it  is  e  al  to  maintain  a  flow  of  information.  ADST  provides  several 
methods  for  dealing  witl.  o  information  management  and  conununications  challenge. 

4.3.1  ADST  Technical  Library. 

Another  LSE  task  is  the  creation,  maintenance,  and  enhancement  of  the  ADST  Technical 
Libraiy.  This  library  is  one  of  the  information  distribution  mechanisms  that  is  needed  to 
facilitate  the  transition  to  the  open  system  architecture.  The  library  gathers  into  one  place  the 
system  description  information  and  infonnation  related  to  and  supporting  ADST  initiatives. 
This  includes  all  of  the  deliverables  creater"  '  T  initiatives,  other  documentation  by  the 
DIS  community,  and  an  historical  repository  of  J^IMNET  infonnation. 

The  initial  base  of  the  collection  was  historical  information  related  to  the  currently  fielded 
SIMNET  system.  This  information  had  to  be  gathered  and  evaluated,  and  as  a  result  it  was 
discovered  that; 

a.  No  one  site  had  a  complete  set  of  the  available  system  documentation. 

b.  Confidence  in  documents  validity  in  relation  to  the  current  system  varied. 

c.  Not  all  systems  were  documented  to  the  level  necessary  to  perform  maintenance. 

d .  It  was  not  clear  which  version  of  the  software  documents  were  related  to. 

e .  Documents  necessary  for  requirements  tracking  were  not  present  for  all  systems. 

As  depicted  in  Figure  4.3. 1  - 1 ,  the  initial  task  was  to  place  under  configuration  management  the 
existing  system  documentation.  This  required  gathering  information  from  primary  sources: 
STRICOM,  Fort  Knox,  Fort  Rucker,  1ST,  and  IDA.  IDA  had  the  most  complete  library,  with 
over  2000  entries  that  have  been  screened  and  added  to  the  ADST  library  as  appropriate. 
STRICOM  had  over  260  documents  and  other  media  in  their  SIMNET  libraiy  that  had  been 
duplicated  and  included  in  the  library.  1ST  had  over  160  documents  in  their  library;  those 
unique  to  that  library  have  been  duplicated.  Fort  Knox  had  over  300  documents  and  Fort 
Rucker  over  100.  The  unique  documents  have  been  identified  and  reproduced. 
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Figure  4.3.1 -1.  Technical  Library  Maintenance  and  Information  Distribution 

To  place  the  documents  and  other  material  under  configuration  management,  a  database 
management  system  (DBMS)  has  been  developed  to  track  document  information.  This  design 
will  facilitate  making  old  and  new  reports  available  to  DTIC.  Each  document  in  the  library  is 
assigned  a  standard  technical  report  number  (STRN)  in  accordance  with  ANSI/NISO  Z39.23- 
1990.  Each  document  also  retains  its  identification  numbers  hum  the  other  libraries. 
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After  the  creation  of  the  base  library  at  the  ADST  PMO,  the  challenges  are  to  make  the 
distribution  of  information  in  the  library  cost-effective  and  to  keep  it  (and  the  supporting 
libraries)  up  to  date.  The  library  inventory  DBMS  will  facilitate  both  of  these  objectives.  Sites 
will  have  on-line  access  to  update  the  database  via  ElEN.  This  will  allow  the  sites  to  update 
their  on-hand  library  holdings,  browse  and  request  entries  in  the  ADST  Master  Library,  and 
recommend  entries  for  inclusion  in  the  master  library.  Data  from  the  DBMS  will  be  uploaded 
to  the  BBS  where  anyone  can  search/browse  the  inventory  information. 

The  general  policy  for  gaining  access  to  library  materials  is  that  a  requester  will  check  out 
material  for  a  24  hour  period.  During  this  time,  requesters  can  use  the  material  and/or  have  the 
material  reproduced.  An  inventory  of  what  is  available  is  maintained  on  the  bulletin  board  and 
is  available  at  the  ADST  PMO.  Special  arrangements  may  have  to  be  made  in  some  instances, 
i.e.,  for  magnetic  media. 

4.3.2  ADST  Bulletin  Board  System  (BBS). 

4.3.2. 1  Bulletin  Board  Configuration. 

The  ADST  Bulletin  Board  System  (BBS)  is  a  primary  means  of  making  technical  information 
available  to  a  wide  community  of  users.  The  BBS  posts  information  to  keep  the  community  up 
to  date  on  ongoing  activities,  and  also  serves  as  a  tool  for  working  groups  in  specific  content 
areas.  Table  4.3.2.1-1  is  a  brief  outline  of  the  topic  areas  available  on  the  BBS. 
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Table  4.3.2. 1  - 1 .  ADST  BBS  Configuration 


ADST  Bulletin  Board  System 


Distributed  Simulation  Initiatives 

SIMNET  to  DIS  Protocol  Translator  1ST  LOSIMSteering  Committee  (Private) 

Estelle  Specification  Project  DIS  Conference  Minutes 

AL5P  -  Aggregate  Level  Simulation  1ST  Coordinate  Xfonn  SW 

Protocol 

DIS  Architecture 

DIS  Architecture  Comments 
Volume  I:  Summary  Discription 

Volume  II:  Supporting  Rationale  Book  I:  Time/Space  Coherence 
Volume  II:  Supporting  Rationale  Book  II:  DIS  Architecture  Issues 
DIS  Standard  Documents 
Rational  Document 
DIS  Standard  2.0  First  Draft 
DIS  Standard  2.0  Second  Draft 
DIS  Standard  2.0  Third  Draft  #209  (2) 

DIS  Software 

ADA  Code 
CCode 

Comments  on  DIS  Software 
DIS  Testing 

DIS  Test  PlanVS.O 
IITSC'92 

Battlefield  Distributed  Simulation  *  Developmental 
BDS-D  User's  Guide 
DIS  Compliance  and  Capability 
Common  Database  Standard  1.1  (MS  Word  for  Mac) 

1ST  Computer  Generated  Forces 

ISTCGFV4.210  9-30  PDU  Streams 

1ST  CGF  V6.0  (DIS)  10-22  data  logger  update 

1ST  CGFV6.002  Update  ISTCGFV6.400 

Utilifies  1ST  CGF  V6.405  (IEEE  1278  Std) 

Terrain  Data  Bases  1ST  CGF  V6.407  (DIS  2.0.3  Std) 

Position  Papers 

Recommended  Approach  for  Standardizing  DIS  Data  Base  Color... 

Army  Air  Defense  Challenges  to  the  DIS  Standard 

ANALYSIS  OF  THE  DIS  PROTOCOL  FOR  DARPA’s  PROJECT  HY-DY 

Euler  Angle  &  Rotation  Matrix  Conversion  between  DIS  and  SIM... 

SIMNET  Local  Coordinate  -  DIS  1.0  CJeocentric  Coordinate  Tran... 

ADST  Technical  Library 

This  report  provides  a  listir^  of  the  documents  avaUable  in  the  LORAL  ADST  Technical 

ibrary. 
pcoming  Conferences 

9th  DIS  ConfererKe 
onunents  and  Discussions 

Add  messages  to  this  area  if  you  have  any  questions.  Or  if  you  have  suggestions  on 
irrformation  you  would  like  to  see  maintained  on  the  BBS,  topic  areas  that  you  would  like  to 
see  added  or  other  comments. 


ADST/WDL/TR--94-0301 7-V3.0 
1994 _ 


ADST  System  Deflnition  Document 


10  March 


To  facilitate  communication  among  members  of  the  simulation  community,  a  listing  of  Internet 
Electronic  Mail  addresses  is  maintained  on  the  ADST  Bulletin  Board  System.  Messages  and 
brief  position  papers  may  be  passed  easily  among  interested  BBS  subscribers. 

All  BBS  users  will  have  to  be  registered  to  ensure  accountability  and  network  security.  There 
are  no  "guest"  or  "anonymous"  accounts.  All  users  requesting  access  to  the  BBS  will  have  to 
fill  out  a  registration  request  form.  This  form  will  be  sent  to  the  Loral  ADST  office  in  Orlando 
Upon  receipt  of  the  registration  form,  the  user  will  be  added  to  the  BBS  system  and  will  be 
assigned  a  password.  The  user's  password  and  other  pertinent  BBS  information  will  be  sent, 
to  the  user  via  U.S.  Mail.  Once  users  receives  this  information,  they  can  log  on  to  BBS  and 
change  their  password  to  something  only  the  user  knows. 

The  BBS  is  configured  by  Groups  and  Sub-Groups.  Each  Group  and  Sub-Group  may  have 
multiple  Sub-Groups  under  it.  Each  Group  and  Sub-Group  will  have  a  responsible  person  as 
the  administrator.  The  "administrators"  will  not  be  the  BBS  System  Administrators,  but  will 
be  actual  users  with  authority  over  the  Group  and  Sub-Groups.  Systems  Administration  will 
be  required  only  to  create  Groups,  not  Sub-Groups. 

These  groups  can  be  Read  or  Read/Write  for  all  users  or  only  specified  users.  Read  and 
ReadAVrite  users  can  also  be  mixed  in  the  same  Group  or  Sub-Group. 

4.3.2. 1.1  ADST  BBS  Components. 

This  BBS  is  available  24  hours  a  day  via  Dial-In  and  Internet.  A  block  diagram  of  the  BBS 
components  is  shown  in  Figure  4.3.2. 1. 1- 1.  BBS  equipment  is  summarized  in  Table 
4.3.2.1.1-1.  The  INTERNET  address  of  the  BBS  is  137.249.32.17.  The  BBS  modem 
telephone  number  is  (408)  428-9470.  The  following  suite  of  hardware  supports  the  BBS. 
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Internet  Access  to  BBS  using  "Telnet"  protocol 


2.4  GB  I 
Disk 

Storage  ' 

Sun  CD 
Player 


TEAMate  BBS 
Software 


SPARCstation2 
Loral  San  Jose 


1/4" 

Tape 

Drive 


8mm 

Tape 

Drive 


Dial-In  Access  to  BBS 

4  US 

Robotics 

HST 

9600 

Modems 


Figure  4.3.2. 1 . 1  - 1 .  ADST  BBS  Block  Diagram 


Table  4.3.2. 1.1-1.  BBS  Equipment 


QUANTIT 

Y 


■EhmmIH 

Sun 

SPARCstation 

'J 

BBS  Server 

64  MB  Memory 

2.4  GB  Disk  Storage 

2.3  GB  8mm  Tape  Storage 
150MB  1/4"  Tape  Storage 
Sun  CD  Player 

US  Robotics 
HST  9600 
Modems 

Self-adjusting  in  speed  and 
protocol  to  suppon 

V42,  V42bis 

MNP-5  Compression/ 

Enor  Correction 

Telebit 
TrailBlazer  + 
Modems 

UUCP  Support.  Self- 
adjusting  in  speed  and 

V42,  V42bis 

MNP-5  Compression/ 

Error  Correction 

PURPOSE 


For  BBS  application  and  file  storage. 

For  backup  and  information  upload  and  downf 
For  backup  and  information  upload  and  downl 
For  system  use  and  information  upload. 


cunently  manufactured  modems  at  the  highe 
speed  available  to  both  modems. 


protocol  to  support  cunently  manufacturec 
modems  at  the  highest  speed  available  to 
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Table  4.3.2. 1.1-2.  TEAMate  Features 


FEATURE 

FUNCTION 

Point  and  Select  Outline  Database 

Unique  TEAMate  feanire  for  ease  of  use. 

User  Interface 

Full  Screen  cursor  controlled.  Forms  for  data  entry.  Context 
sensitive  help.  User  interface  may  be  customized. 

Simultaneous  Users 

Unlimited.  Restricted  only  by  host  capacity 

Electronic  Mail 

Included  with  cc:,  bcc:,  groups,  auto  receipt  notification,  foreign  mail 
gateways. 

Bulletin  Boards 

Easy  to  use  topic  (menu)  oriented  with  definable  access  permissions. 
Group  and  individual  membership. 

Computer  Conferences 

Topic  oriented  electronic  meetings. 

Chat 

Interactive  group  discussions  with  scrollable  and  saved  transcripts. 

Easy  dual  window  interface. 

Private  Topics 

Membership  in  topics  can  be  limited. 

Immediate  Indexing 

All  information  is  indexed  upon  creation  fro  immediate  retrieval. 

Content  Retrieval 

Retrieval  on  subject,  author,  keywords,  reference,  topic,  creation  date, 
expire  date.  Full  text  retrieval  optional. 

Viewable  Indexes 

All  indexes  may  be  viewed  with  frequency  counts. 

Data  Transfer 

Transaction  processor  supports  loading/unloading  bulk  data. 

Dynamic  Data  Reorganization 

All  data  can  be  reorganized  on-line.  Owners  can  change  the  structure. 
Menu  items  (topics)  can  be  hoisted  or  lowered  as  desired. 

Binary  Files  and  Downloads 

Unlimited  download  libraries.  Compound  entries  supported  for 
attaching  descriptive  text  to  binary  files. 

Audit  Trails 

Topic  and  Entry  tracking. 

Network  Support 

Modems  (all  speeds),  X.25  and  local  high  speed  networks 

Word  Processors 

TEAMedit  provided  and  all  UNIX  editors  and  word  processors 
supported. 

System  Operation 

Administrative  functions  built  in.  User  directory  maintained  by 
TEAMate.  All  functions  can  be  performed  while  system  is  in  full 
operation. 

Customization 

Screen  layouts,  command  names,  command  deletion,  help  files.  No 
customization  reouired  for  standard  operation. 

Forms 

Form  builder  permits  building  customized  data  input  forms. 

Terminal  Emulation 

Supports  all  cursor  addressable  terminals.  TEAMterm,  MS-DOs 
communication  program,  provided  with  unlimited  duplication  license. 

4.3.3  Defense  Technical  Information  Center  (DTIC). 


The  ADST  contract  has  become  a  registered  user  of  DTIC;  documents  can  requested  and 
submitted.  The  submission  of  documents  to  DTIC  is  aided  by  the  information  gathered  and 
tracked  in  the  ADST  Technical  Library. 
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APPENDIX  A:  RESEARCH  AREAS 

This  appendix  addresses  research  areas  which  are  listed  in  the  ADST  SOW  which  are  being 
addressed  by  D.O.s.  Further  information  about  the  D.O.s  is  listed  in  Table  A-1  below. 


Table  A- 1.  ADST  Research  Areas 


RESEARCH  AREA 

ADST  ACTIVITIES 

COMMENTS 

Battle  Simulation  for  Individuals,  Crews, 
and  Units 

CVCC,  CSRDF 

Cost  Effective  Long  Haul  Networking 
Capability 

BDS-D,  CSRDF 

BDS-D  Network  architecture; 
CSRDF  demonstration. 

Networking  of  Simulators  with  Varying 
Levels  of  Resolution 

CSRDF 

NASA-Ames  and  AVTB  rotary 
wing  simulators 

Networking  of  Manned  Simulators  and 
Computer  Simulations 

BDS-D  IHOM 

Demonstration  planned  for  IHOM 
Step  2. 

1  Seamless  Simulation  Between  Manned  and 
Automated  Simulators,  and 

Field/Command  Post  Exercises 

BDS-D  CGF 

Integration  of  Manned  and 
Automated  Simulators  only;  FTX 
and  CPX  not  vet  addressed. 

Low  Cost  Visual  Simulation  Technoloev 

BDS-D  DIS  V&V 

Rapid  Terrain  Database  Generation 

Tactics,  Technology,  and  Virtual 

Prototypes  in  a  Low  Cost,  Variable 
Resolution,  Modular  Developmental  Test 
Bed 

X-ROD,  VIDS 

X-ROD  developing  virtual 
prototype  and  COEA.VIDS 
survivability  systems  prototyping 

Instructional  System  Development 

H  Procedures 

H  Man-machine  Interface,  e.e.,  MANPRINT 

AirNet  Conversion 

Task  analysis 

Embedded  Training  and  Actual  Equipment 
in  Distributed  Simulation 

N/A 

Human  Performance  and  Measurement 

Re  configurable  and  Prototype  Combat 
Vehicle,  Aviation,  and  Shipboard  Combat 
System  Control  Simulators 

AirNet  Conversion 

Reconfigurable  simulators 

System  Requirements  Analyses  Methods 

Analytical  Methodologies  for  "man  in  the 
loop  training" 

N/A 

Emerging  Development  in  Display 
Technology 

BDS-D,  AirNet 
Conversion 

Computer,  Electronic  and  Mechanical 

1  Systems 

AirNet  Conversion 

1  Engineering  Management  Systems 

N/A 

H  Training  Technologies 

BDS-D 

R  Artificial  Intelligence 

BDS-D  CGF 
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APPENDIX  B;  ADST  POINTS  OF  CONTACT 

USA  STRICOM: 

12350  Research  Parkway 
Orlando,  FL  32826-3276 

Mr.  Stan  Goodman,  BDS-D  Program  Manager 
(DSN)  960-8165,  (407)  380-8165,  FAX:  (407)  380-4258 
e-mail:  goodmans@orlando-einh7.aimy.inil 
Mr.  Gene  Wiehagen,  COTR 

(DSN)  960-4363,  (407)  380-4363,  FAX:  (407)  380-4258 
e-mail:  wiehageg@orlando-emh4.army.mil 
Mr.  John  Collins,  COTR 

(DSN)  960-4382,  (407)  380-4382,  FAX:  (407)  380-4258 
e-mail:  collinsj@orlando-emh4.army.mil 

Loral  ADST  Program  Management  Office 
12443  Research  Parkway,  Suite  303 
Orlando,  FL  32826 

Mr.  Warren  Richeson,  ADST  Program  Manager 
(407)  382-458 1 ,  FAX:  (407)  382-4592 
e-mail:  richeson@orlando.loral.com 

Mounted  Warfare  Test  Bed 
2021  Blackhorse  Regiment  Ave. 

Fort  Knox,  KY  40121 

Mr.  Tom  Radgowski,  Site  Manager 
(502)  942- 1 092,  FAX:  (502)  942- 1 696 

e-mail:  radgowski@vox.knox.loral.com 

Aviation  Test  Bed  Facility 
PO  Box  385 
Fort  Rucker,  AL  36362 
Mr.  John  Miller,  Site  Manager 
(DSN)  558-2234,  (205)  598-3066,  FAX:  (205)  598-5370 
e-mail:  miller@charm.isi.edu 
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APPENDIX  C:  DELIVERABLES  AND  PRODUCTS  BY  DELIVERY  ORDER 


DATES 

DELIVERY  ORDER 

DELIVERABLES/  PRODUCTS 

04/91  -  08/91 

CVCCSTEPI  D.O. 

Feasibility  Analysis  Study 

04/91  -09/91 

RWA  STEP  1  D.O. 

RWA  Design 

05/91  -  02/93 

DOTDSTEP2  D  O. 

Final  Report  Submitted 

07/91  -  06/92 

MULTIRAD  STEP  2  D.O. 

Protocol  Extension  to  SIMNET  Submitted 

Long  Haul  Network  Submitted 

Network  Performance  Analysis  Submitted 

Computer  Software  Product  Submitted 

10/92  -  02/92 

RWA  STEP  2 

CWBS  Submitted 

System/Segment  Spec  Submitted 

Deyelopment  DES  DWGs  and  Assoc  Lists 

Design  Criteria  List  Submitted 

System  Safety  Program  Plan 

Safety  Assessment  Report 

Software  User’s  Manual 

Facility  Design  Criteria  Doc 

Test  Plan/Proc 

Test  Plan/Proc 

Recommended  Spates/Supt  Equip 

08/91  -07/93 

CVCC  STEP  2 

Test  Plan  for  HW/SW/INT  (submitted  10-18-91) 

Test  Plan  for  HW/SW/INT  (submitted  03-16-92) 

Test  Results:  HW/SW/INT  (submitted  08-01-92) 
Test  Results:  HW/SW/INT  (submitted  10-01-92) 
ECR  Workstation  Manual  Update  (submitted) 
Utilities  Manual  Update  (submitted) 

Hardware  Users  Guide  (submitted) 

Research  Report  (submitted  09-12-92) 

Research  Report 

Goyt.  Furnished  Research  Plan/  Support  Package 
Software  Users  Guide  (submitted) 

Software  Architecture  Description  (submitted) 
Innovative  Training  Methods  (submitted) 

Innovative  Training  SW  Description  (submitted) 
Briefing  Slide  Library  (submitted) 

10/91  -  03/92 

BDS-D  STEP  1  D.O. 

Provide  Technical  Report 

Provide  Cost  Proposal 

10/91  -05/92 

LSFBD  STEP  1  D.O. 

Reconfigurable  Sim  Funct  Req  Doc 

Reconfigurable  Sim  Des  Data  Harxlbook 
Reconfigurable  Sim  Funct  Spec 

SIMNET-JANUS  Intercon  Desc  Data  Handbook 
SIMNET-JANUS  Test  Scenario 

SIMNET-JANUS  Funct  Rea  Doc 

11/91  -07/93 

X-ROD  STEP  2  D.O. 

Outline  Test  Plan 

Draft  Funct  Spec 

Test  Des  Plan 

Phase  2  Approach/Schedule 

Detailed  Test  Plan 

Final  Functional  Spec  Doc 

HW/SW  Mod  Doc 

10/91  -  01/92 

CSRDF  STEP  1  D.O. 
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03/92  -  06/93 

CSRDF  STEP  2  D.O. 

Step  2  Requirement  Doc 

ICD 

Step  2  Proposal 

FAS  Report 

06/92  -  07/92 

VIDS  STEP  1  D.O. 

Step  2  Proposal 

Feasibility  Analysis  Report 

APPENDIX  C:  DELIVERABLES  AND  PRODUCTS  BY  DELIVERY  ORDER 

(CONTINUED) 


DATES 

DELIVERY  ORDER 

DELIVERABLES  /  PRODUCTS  | 

04/92  -  02/93 

LEAVENWORTH  STEP  2 
D.O. 

Requirements  Specification  | 

Requirements  Specification  | 

Feasibility  Repoit  | 

Feasibility  Report  | 

06/92  -  07/93 

AirNet  STEP  2  D.O. 

Design  Criteria  List  | 

S/W  Maintenance  Manual 

Test  Plans/  Procedure  (prelim) 

Test  Plans/  Procedure  (final) 

Rec  Spares  and  support  Equip 

Software  Design  Dm 

MCC  Operator’s  Manual 

AirNet  Conversion 

Dev  Des  Dwgs  and  Assoc  Lists  (prelim) 

Dev  Des  Dwgs  and  Assoc  Lists  (final) 

07/92  -  06/93 

BDS-D  STEP  2  D.O. 

Arch  Def  Phase  2  Plan 

DIS  Arch  Standards  Phase  2  Plan 

DIS  Architecture  Description  Doc 

BDS-D  Ver.  1 .0  Sys  Des  Spec 

BDS-D  Ver.  1.0  Sys  Des  ICD 

Common  Database  Standard 

DIS  PDU  EXTENSION 

DIS  Correlation  Metrics 

BDS-D  System  Plan 

Intg  w/BDS-D  Ver  1.0  Sys  Phase  2  Plan 

Large  Scale  Exercise  Plan 

Phase  2  Plan  for  fully  Represented  Theater 
Component  Demo  Test  Plan 

Component  Demo  Report 

DIS  Demo  Test  Plan 

DIS  Demo  Report 

Outline  Plan  and  Brief 

S/W  Des,  Sys  A  Code  Doc  and  Reports 

07/92  -  07/93 

WARBREAKER  STEP  2 
D.O. 

Comp  SW  Prod  End  Items 

Software  Design  Document 

Software  Design  Document 

Protocol  Extension  to  DIS 

Network  Analysis 

Network  Analysis 

Software  User’s  Manual 

Interface  Design  Document 

Final  Report 
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07/92  -  08/93 

VIDS  STEP  2  D.O. 

Software  Design  Doc 

Software  Maintenance  Manual 

Operators/users  Manual 

Test  Plan 

Test  Report 

NLOS  STEP  2  D.O. 

Test  Plan 

09/92  -  09/93 

Design  Drawings  (draft) 

Design  Drawings  (final) 

Operator  and  Maint  Manual 

Software  Design  Doc 

Test  Repoit 

Software  Reference  Manual 

09/92  -  03/93 

SMART  MINES  STEP  2 

Technical  and  Management  Woric  Plan 

Technical  Report  (draft)  H 

Technical  Report  (final)  || 

APPENDIX  C:  DELIVERABLES  AND  PRODUCTS  BY  DELIVERY  ORDER 

(CONTINUED) 


DATES 


09/92  -  04/93 


1 1/92  -  10/93 


05/92  -  05/92 


10/92  -  10/92 


08/92  -  03/93 


DELIVERY  ORDER 


BSD  STEP  2  D.O. 


MODSAF  STEP  2  D.O. 


SASC  DEMO  STEP  2  D.O. 


LOSAT/SAFDI  DEMO 


JAYHAWK  THUNDER 


DELIVERABLES  /  PRODUCTS 


Hardware  Drawings 
Operator’s  Manual  Change  Pages 
Technical  Manual  Change  Pages 
Final  Report 

Software  Design  Document 


Programmers  Reference  Manual  -  D 
Programmers  Reference  Manual  -  F 
SAPOR  Operator  Users  Manual  -  D 
SAFOR  Operator  Users  Manual  -  F 
Computer  System  Operations  Manual  -  D 
Computer  System  (^rations  Manual  -  F 
Interface  Control  Dorament  -  D 
Interface  Control  Document  -  F 
System  Requirements  Specification 
Acceptance  Test  Procedure  -  D 
Acceptance  Test  Procedure  -  F 
Version  Description  Document 
Installation  Plan  -  D 
Installation  Plan  -  F 
Training  Plan  -  D 
Training  Plan  -  F 
Maintenance  Plan  -  D 
Maintenance  Plan  -  F 
Recommended  Spares  List _ 


Stage  1  Report 
Final  Report 

Software  Description  Document 
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09/92  -  01/94 

CVCC  93 

01/93-01/94 

BRIEFING  D.O. 

06/92  -  08/92 

M1A2  SUPERTHREATS 

12/92-03/93 

SEAMLESS  SIMULATION 
EXP 

03/93  -  02/94 

DOS 

03/93  -  07/93 

PVI 

04/93  -  08/93 

TEST  BED  EXPANSION 

05/93  -  1 1/93 

VIDS  PHASE  II 

05/93  -  1 1/93 

SKALNOTTY 

03/93  -  06/93 

CTPS  (AUSA  MAY) 

APPENDIX  C 

:  DELIVERABLES  AND 

(CONTI 

DATES 

DELIVERY  ORDER 

05/93  -  08/94 

PROJECT  SWORD 

06/93  -  03/94 

A/S  PHASE  2 

06/93  -  08/93 

M1A2  DIFFERENTIAL 

06/93  -  01/94 

NATIONAL  GUARD 

06/93  -  01/94 

ARWA  PHASE  1 

07/93  -  12/94 

MULTIRAD/CAS 

02/93  -  1 1/93 

05/06  TOC 

Final  Research  Report  (draft) 
Final  Research  Report  (final) 
Software  Architectural  Document 


Test  Renort 


Test  Report 


Software  Design  Document 
Software  MaintenaiKe  Manual 
Operators/Users  Manual 
Test  Plan 
Test  Renort 


Software  Design  Document 
Technical  Manual 
Operator  and  Maintenance  Manual 
Dev  Des  Drwgs  and  Assoc  Lists 
Test  Renort 


DELIVERABLES  /  PRODUCTS 


ADST/WDL/TR -94-03017-V3.0 
1994 


ADST  System  Definition  Document 


10  March 


APPENDIX  D;  ACRONYMS 


The  acronyms  list  contains  relevant  technical  terms  from  the  architecture,  SIMNET,  DIS,  the 
contract,  and  the  various  D.O.s. 


ADATS 

ADL 

ADST 

AFB 

ATT 

ALSP 

AMSAA 

ARDEC 

ARI 

ASD 

ATACn 

ATAS 

ATCOM 

AVTB 

ATES 

ATCOM 

AWACS 

BARRNet. 

B&W 

BBN 

BBS 

BCIP 

BDS-D 

BFV 

BOS 

CAC 

CADIS 

CAS 

CASS 

CCB 

CCP 

MWTB 

CCTR. 

CCTT 

CDRL 

CET 

CGF 

CGSC 

CIG 

crrv 

CIU 

COFT 

CONOPS 

CM 

CMT 


Air  Defense  Anti-Tank  System 
Ada  Design  Language 

Advanced  Distrilmt^  Sirnulmion  Technology 

Air  Force  Base 

Air  Intercept  Trainer 

Aggregate  Level  Simulation  Protocol 

Army  Material  Systems  Analysis  Activity 

Armament  Research  Development  and  Experimentation  Center.  Picatiimv 
Arsenal 

Anny  Research  Instimte 
Aeronautical  Systems  Division  (of  USAF) 

Air  to  Air  Combat  II 
Air  to  Air  Stinger 
Aviation  and  Troop  Command 
Aviation  Test  Bed 

Automated  Threat  Engagement  System 

Aviation  and  Troop  Command 

Airboume  Warning  and  Control  System 

Bay  Area  Regional  Research  Network 

Black  and  White 

Bolt,  Beranek,  and  Newman 

Bulletin  Board  System 

Battle  Command  Integration  Program 

Battlefield  Distrilnited  Simulation  -  Developmental 

Bradley  Fighting  Vdiicle 

Battlefield  Operating  System 

Combined  Anns  Command 

Computer  Architecture  for  Distributed  Interactive  Simulation 
Close  Air  Support 

Communication  Architecture  and  Security  Subgroup 

Configuration  Control  Board 

Contract  Change  Proposal 

Mounted  Warfare  Test  Bed 

Command  and  Control  Training  Research 

Close  Combat  Tactical  Trainer 

Contract  Data  Requirements  List 

Combat  Engagement  Trainer 

Computer  Generated  Force 

Command  and  General  Staff  College 

Computer  Image  Generator 

Commander's  Independent  Thermal  Viewer 

(Dell  Interface  Unit 

Ctmduct  of  Fire  Trainer 

Concept  of  Operations 

Confi^ration  Management 

Cridcd  Mobile  Targets 
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APPENDIX  D;  ACRONYMS  (continued) 


CPG 

CPO 

CPX 

CR 

CSC 

CSCI 

CSRDF 

CSS 

CTAS 

CVCC 

DAC 

DARPA 

DBMS 

DCD 

DDR&E 

DIS 

DMSO 

DN 

DS,DD 

DSI 

one 

D.O. 

DOD 

ECO 

ECP 

EIEN 

EPLRS 

EW 

FAADS 

FBL 

FCA 

FDT&E 

FLIR. 

FOG-M 

FOV 

FSE 

FTP 

FTX 

FWA 

GADD 

GCI 

GDLS 

GFE 

GPS 

GPS 

HEAT 

HEL 

HEMTT 

HMMWV 

HRA 

HUD 

ICD 


Co-Pilot/Gunner 
Co-Pilot/Observer 
Command  Post  Exercise 
Change  Report 

Computer  Software  Component 

Computer  Software  Configuration  Item 

Crew  Station  Research  and  Development  Facility 

Combat  Service  Support 

Counter  Target  Acquistion  System 

Combat  Vehicle  Command  and  Control 

Digital  to  Analog  Converter 

Defense  Advan^  Research  Projects  Agency 

Database  Management  System 

Director  of  Combat  Development 

Deputy  Director  (of  Defense)  for  Research  and  Engineering 

Distributed  Interactive  Simulation 

Defense  Modeling  and  Simulation  Office 

Discrepency  Notice 

Double  Sided,  Double  Density 

Defense  Simulation  Internet 

Defense  Technical  Information  Center 

Delivery  Order 

Department  of  Defense 

Engineering  Change  Order 

Engineering  Change  Proposal 

Electronic  Information  Exchange  Network 

Enhanced  Position  Location  and  Reporting  System 

Electronic  Warfare 

Forward  Area  Air  Defense  System 

Future  Battle  Laboratory 

Functional  Configuration  Audit 

Field  Developmental  Test  and  Evaluation 

Forward  Looking  Infitd^ed 

Rber-Optic  Guided  Missile 

Field  of  View 

Fire  Support  Element 

File  Transfer  Protocol 

Field  Test  Exercise 

Fixed  Wing  Aircraft. 

Generic  Air  Defense  Device 
Ground  Control  Intercept. 

General  Dynamics  Land  Systems 
Government  Furnished  Equipment 
Gunner's  Primary  Sight. 

Global  Positioning  Satellite 
High  Explosive  i^ti-Tank 
Human  ^gineering  Laboratories 
Hwvy  Expanded  Mobility  Tactical  Truck 
High  Mobility  Multipurpose  Wheeled  Vehicle 
Human  Resources  (Laboratory)  "A" 

Heads-Up  Display 
Interface  Control  Document 
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I-COFT 

Individual  -  Conduct  of  Fite  Trainer 

IDA 

Institute  for  Defense  Analysis 

IFV 

Infantry  Fighting  Vehicle 

IHOM 

Integration  of  Higher  Order  Models 

HR 

Imaging  Infixed 

IP 

Inteniet  Protocol 

1ST 

Institute  for  Simulation  and  Training 

ISU 

Integrated  Sight  Unit 

nr 

Integration  and  Test  Team 

nv 

Improved  TOW  Vehicle 

IVIS 

Inter-Vehicular  Information  System 

JMASS 

Joint  Modeling  and  Simulaticm  System 

JSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

LAN 

Local  Area  Network 

LCAC 

Low  Cost  Auxilliary  Cockpit 

LDN 

Local  Data  Network 

LOSAT 

Line  of  Sight  Anti-Tank 

LSE 

Laboratory  Sustaining  Effort 

MCC 

Management.  Command  and  Control 

MILNET 

Military  Network 

MORS 

Military  Operations  Research  Society 

MPET 

MuItiPlatform  Engagement  Trainer 

MPMC 

MultiPeer/MultiCast 

MULTIRAD 

Multiship  Research  and  Development  (Facility) 

NCCOSC 

Naval  Command,  Control,  and  Ocean  Surveillance  Center 

NETT 

New  Equipment  Training  Team 

NIU 

Network  Interface  Unit 

NLOS 

Non-Line-Of-Sight 

NOM 

Network  Operations  and  Maintoiance 

NRaD 

Navy  Research  and  Developmmit 

NFS 

Network  File  System 

NSC 

National  Simulation  Center 

NSFNET 

National  Science  Foundation  Network 

NTC 

National  Training  Center 

NTSC 

Naval  Training  Systems  Command 

OOS 

Operational  O^rating  Systems 

OPFOR. 

Opposing  Force 

OPORDERS 

Operation  Orders 

OPS 

Operations 

OIW 

Out  The  Window 

PCA 

Physical  Ccmfiguration  Audit 

PDL 

Program  Design  Language 

PICT 

a  graphic  fomuit  standard 

POSNAV 

Position  Navigation 

PDU 

Protocol  Data  Unit 

PMO 

Program  Management  Office 

POC 

Point  of  Contact 

PVD 

Plan  View  Display 

RCS 

Revision  Control  System 

RDT&E 

Research,  Development,  Test  and  Evaluation 

RPA 

Rotocraft  Pilot's  Associate 

RWA 

Rotary  Wing  Aircraft 
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SAAC 

Simulator  for  Air  to  Air  Combat 

SAP 

?emi-Automated  Porces 

SAPOR 

Semi-Automated  Porces 

SAKI 

Saudi  Arabia,  Kuwait  and  Iraq  (terrain  database) 

SAS 

Statistical  Analysis  System 

see 

Simulation  networking  Control  Consoles 

SCM 

Software  Configuration  Management 

SCN 

Specification  (Change  Notice 

SCRB 

Software  Configuration  Review  Board 

SCTB 

Simulator  Complexity  Test  Bed 

SDP 

Software  Development  Pacility 

SHORAD 

Short  Range  Air  Defense 

SIP 

Standard  Interface  Pormat 

SIMNET 

Simulation  Networking 

SIMWORLD 

Simulation  World 

SMI 

Soldier  Machine  Interface 

SMS 

Smart  Minefield  Simulator 

SINCGARS 

Single  Chaimel  Ground  and  Airborne  Radio  System 

SOP 

Standing  Operating  Procedure 

SP 

Software  Problem 

SPR 

Software  Problem  Report 

SRC 

Source  (code) 

SSL 

Software  Support  Library 

SSOP 

Software  Support  Operating  Procedures 

STRICOM 

Simulation,  Training  and  Instrumentation  Command 

STRN 

Standard  Technical  Report  Number 

T&E 

Test  and  Evaluation 

TACOM 

Tank  Automotive  Command 

TCP 

Transmission  Control  Protocol 

TEC 

Topographic  Engineering  Center 

TNE 

Threat  and  Natur^  Envirorunent 

TOC 

Tactical  Operations  Center 

TOR 

Technical  Oversight  Representative 

TOW 

Tube-launched,  (^tically  Wire-guided 

TRAC 

TRADOC  Analysis  Onter 

TRADOC 

US  Army  Training  and  Doctrine  Command,  Port  Monroe 

USA. 

United  States  Army 

USAP 

United  States  Air  Porce 

UTP 

Unshielded  Twisted  Pair 

VADPC 

Video/ Audio  Data  Production  Center 

VTRS 

Visual  Technology  Research  Simulator 

v&v 

Verificatiion  and  Validation 

VHS 

Video  Home  System 

VIDS 

Vehicle  Integrated  (Defense  System 

VMS 

Virtual  Machine  System  (DEC  Operating  System) 

W&A 

Verification,  Valit^tion,  and  Accreditation 

WAN 

Wide  Area  Networlc 

WAREX 

War  Exercise 

WDL 

Western  Development  Laboratories  (a  Loral  Company) 

WISSARD 

What  If  Simulation  System  for  Aircraft  Researdi  and  Development 
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